The Arsenal Files 1/The Arsenal Files (Arsenal Computer).ISO/os2_app/os2techg.inf

OS/2 Help File | 1993-10-27 | 631KB | 8,537 lines

ΓòÉΓòÉΓòÉ 1. Title Page ΓòÉΓòÉΓòÉ



                          A Technical Guide to OS/2 2.0

                                  January 1993

                                 Martin McElroy

                     European Personal Systems Center (EPSC)
                                      Basingstoke
                                               UK
                                     MCELROM at NHBVM7
                                      [phone]


                              Converted to IPF by:
                                Leshek Fiedorowicz
                                  CIS#74170,2007


ΓòÉΓòÉΓòÉ 2. Notices ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 2.1. Trademarks ΓòÉΓòÉΓòÉ

The following terms are trademarks or registered trademarks of the IBM
Corporation in the United States and/or other countries:

 OS/2                                              Extended Services
 Presentation Manager                              NetView
 WIN-OS/2                                          Workplace Shell
 AIX                                               IBM
 DB2                                               DDCS/2
 Operating System/2                                SQL/DS
 OS/400                                            RISC
 PS/2                                              RISC System/6000
 Systems Application Architecture                  SAA
 SAA Distributed Database Connection Services/2    SQL
 System/370                                        Audio Visual Connection

All trademarks appearing in this document are owned by their respective
companies.


ΓòÉΓòÉΓòÉ 2.2. Disclaimer ΓòÉΓòÉΓòÉ

Some of the information in this paper concerns future products, or future
releases of products currently commercially available. The discussion regarding
Microsoft Windows is based upon information which the Microsoft Corporation has
made publically available, and is subject to change.  The description and
discussion of IBM's future products, performance, functions and availability
are based upon IBM's current intent and are subject to change.


ΓòÉΓòÉΓòÉ 2.3. Special notices ΓòÉΓòÉΓòÉ

References in this publication to IBM products, programs, or services do not
imply that IBM intends to make these available in all countries in which IBM
operates.

Any reference to an IBM program, product or service is not intended to imply
that only IBM's program, product or service may be used. Any functionally
equivalent program, product or service may be used instead.

IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not imply giving any
license under any patent or pending patent.


ΓòÉΓòÉΓòÉ 3. Preface ΓòÉΓòÉΓòÉ

This document describes the features and benefits of OS/2 Version 2.0 from a
technical perspective.  It is aimed at customer technical staff, software
developers, IBM staff, dealers and business partners, and anyone else who needs
to understand the detail of how OS/2 2.0 has been designed and implemented.
Its primary aim is to help those evaluating the product to understand why OS/2
2.0 is the platform of choice for the 90s.

The structure of the document is designed to lead the reader from an awareness
of the needs of the PC systems of the 90s, to an understanding of how OS/2 2.0
meets those needs. It therefore covers the design of OS/2 as well as its key
features, and goes on to discuss future directions for OS/2.  The guide can
either be read sequentially, in its entirety, or individual sections may be
used for reference purposes, relating to specific aspects of OS/2 (such as DOS
compatibility).  To help in the latter use, here is a summary of the aim and
contents of each section:

OS/2 Version 2.0 sets the background against which OS/2 has been developed. It
describes how the PC environment is radically different from that of the 80s,
and the resulting needs of customers deploying PC systems. It also recounts how
OS/2 has been designed to address those needs, culminating in release 2.0.

Why OS/2? outlines the most important reasons why OS/2 is the platform of
choice for the 90s. It is a summary of the arguments provided in the rest of
the document. It can be regarded as a management summary, and as such is
designed so that it can also be used standalone, separate from the rest of the
document. It is suitable for use in proposals, or customer reports on OS/2 2.0.

OS/2 2.0 key elements prefaces the three chapters on DOS, Windows and OS/2
support that follow, by describing some of the technologies that underpin the
whole system. Features such as multi-tasking, hardware support, 32-bit design
and Multiple Virtual DOS Machines (MVDM) are the foundation for many of the
specific aspects described in the three sections that follow. They are also
fundamental to understanding OS/2's superiority to DOS-based systems.

Better DOS describes the extensive support for DOS applications, and the ways
in which OS/2 2.0 provides a better environment for running DOS applications
than DOS itself. This section includes discussion of the memory usage,
protection and the steps taken to ensure the widest possible compatibility with
existing DOS applications.

Better Windows begins by explaining some of the aspects of DOS/Windows 3.x, in
order to show how OS/2 2.0 provides a better Windows environment. An important
factor is the discussion of how DOS/Windows 3.x is used widely for running
multiple DOS applications, perhaps even more than for running Windows
applications. This leads on to a description of how OS/2 2.0 is a superior
multi-DOS environment, which also runs Windows applications, supporting Windows
features such as DDE, clipboard and OLE. The section concludes with a brief
discussion of why many developers are already porting their Windows
applications to OS/2, and some of the tools available to help.

Better OS/2 describes some of the additional features in OS/2 2.0 compared with
OS/2 1.3.  It illustrates the benefits of a 32-bit OS/2, and discusses
migration from 16-bit OS/2 1.x.

Workplace Shell discusses the user interface of OS/2 2.0. It begins by
outlining the reasons why OS/2 2.0 uses a new user interface model, and the
benefits it provides. Emphasis is placed on the fact that users have greater
flexibility to work the way they want, and concentrate on the information they
are working with, not the steps the computer needs to follow. This section also
describes some of the components and features of the Workplace Shell, comparing
them with older GUI systems like DOS/Windows.

OS/2 in a connected environment points out how OS/2 2.0 is the client of choice
in client-server systems, and is the base for a family of products which
connect the OS/2 client into LAN, mini and host based systems, including open
systems. Some of the OS/2 products that offer these features (Extended
Services, OS/2 LAN Server, TCP/IP for OS/2) are briefly described.  Another
crucial element in considering connected, rather than standalone systems, is
the ability to support systems management tools, so that the cost of
maintaining and managing the system does not exceed the benefits.  This section
also discusses migrating from older connectivity products such as DOS-based
terminal emulators and networking products.

Futures describes some of the areas in which OS/2 is expected to be enhanced to
address the growing sophistication of PC usage, and emerging technologies such
as distributed computing, multimedia and object-oriented technology. It aims to
provide an understanding of the framework within which OS/2 will continue to
develop throughout the 90s.

The Appendices give some background information on OS/2 2.0 and comparisons
with other environments.

Appendix A  compares OS/2 2.0 features with those of DOS/Windows 3.x, including
            a detailed comparison of support for DOS applications
Appendix B  discusses the hardware requirements for OS/2 2.0 and gives a
            summary of performance considerations and tuning hints.
Appendix C  gives a guide to other books, publications and materials relating
            to OS/2 2.0, where the reader may find more information.

To use the guide most effectively, it is important not only to understand its
contents, but also its purpose.  Although the document is technical in nature,
it does not aim to be a technical reference.  This is beyond the scope of a
document of this length.  Those looking for such details should consult the
OS/2 Technical Compendium referenced in the Appendices (see  Further reference
materials ).  This guide stands in technical content and level of detail,
between the product information brochure, and the comprehensive discussion of
the OS/2 Technical Compendium.

The guide covers OS/2 function in the release made generally available at the
end of March 1992.  It gives some discussion of planned updates to be made
available during 1992, but details may change before such updates are
available.  Readers are advised to check with IBM representatives or Authorised
Dealers for specific dates and functions.

Although this guide is suitable as an introduction to OS/2 for software
developers, it is NOT intended as a developers' guide. Issues for programmers
are dealt with only as they affect the fundamental OS/2 architecture or in as
much as they concern the OS/2 user. More detailed information for OS/2
programmers may be obtained from your local IBM contacts or via the OS/2
Developer Assistance Program, or on local bulletin boards or Compuserve.

No guide to OS/2 can pretend that the product exists only in a standalone
environment. The chapter OS/2 in a Connected Environment discusses how OS/2 2.0
is ideally suited to the needs of the connected PC, whether it be LAN-based, or
integrated within an enterprise network. It also describes in brief some of the
other members of the OS/2 family, such as Extended Services for OS/2, or OS/2
LAN Server. However, detailed discussion of these products would probably
double the size of the document. A separate technical guide covering the OS/2
systems extensions is planned (contact your IBM representative for more
information).

References to Microsoft Windows 3.x are made to denote the versions of Windows
currently available (3.0 and 3.1) which act as an extension to DOS, running on
a DOS base.  The term, "Windows 3.x"  is used throughout the guide where the
comment is applicable to both 3.0 and 3.1.  A specific version number is used
when talking only about one or other release.  References in this document to
Windows/NT (which Microsoft has announced they expect to ship in 1993) are
based on information which the Microsoft Corporation has made publicly
available.


ΓòÉΓòÉΓòÉ 4. OS/2 Version 2.0 ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 4.1. The changing PC environment ΓòÉΓòÉΓòÉ

In 1981, when IBM introduced the first IBM Personal Computer, no-one
anticipated how much it would change the face of the computer industry. In the
first half of the 1980s, PC use was mainly confined to improving personal
productivity by using spreadsheets, word processors and other widely available
applications.

However, it has been clear from the mid-1980s and beyond that the PC needs to
perform a broader role in the organisation. As greater amounts are spent on PC
technology, more is being demanded, and increasingly the PC is being seen as a
"window" on the enterprise, a single screen from which company-wide information
resources can be accessed, and a base for mission critical, "line-of-business"
applications that previously would only have run on a mainframe. Thus, PCs have
been increasingly connected together in Local Area Networks (LANs) and to host
computers, making them a critical part of the corporate data network.

In addition, new technologies like Graphical User Interfaces (GUIs) and
multimedia, along with greater connectivity, offer the potential to provide
even more information in an easily accessible manner, so that not only can more
uses be found for PCs, but also more users. In this way, PCs can be used to
transform the business, not just increase productivity or automate existing
processes.

And the trend towards "rightsizing" applications continues, moving critical
applications to PCs on a LAN, using a client-server approach. The market
analysts Forrester Research published a report in May 1992, identifying the
growth in demand for a new "super client", driven by the migration of business
applications towards LANs and client-server.

Unfortunately, much of this remains an aspiration, rather than reality. An
article in a June 1990 issue of PC Week said that the PC must now "grow up",
saying that PCs must be considered as "business tools", not "microcomputers".

But a number of requirements must be in place before the PC can "grow up" and
before the "super client" can emerge:

o "Industrial Strength" reliability:  unless the PC can demonstrate itself to
  be as robust an environment as the host computer, it cannot expect to take
  over some of the applications the host runs today, nor even participate fully
  in sharing those applications via a client-server or co-operative processing
  setup.  There is little point in having a reliable server or host if the
  client platform is unstable.

o Networking "Built In": the PC environment needs to allow straightforward and
  simultaneous connection to a variety of other platforms: LAN, mid-range, UNIX
  and mainframe, and to be able to handle the variety of communications
  protocols that results from the multi-vendor environment in most companies.

o Performance:  the PC platform must demonstrate that it can adequately share
  the processing load, by exploiting the power of the base hardware.  Since
  most client-server and connectivity applications will require multiple
  processes, the ability to run several concurrent tasks efficiently is
  fundamental.  In this respect, the requirement for performance measurement
  goes beyond the simple benchmarking of one application at a time, and leads
  towards determining overall throughput and concurrency.

o Wide Application Choice: the platform of the 90s should build on
  compatibility with existing productivity applications, and allow
  "mission-critical" applications to be developed for the same platform, so
  that the user's system can handle both business and productivity
  applications.

o Ease of use and low training costs:  in expanding the use of the PC,
  additional complexity in terms of communications and multiple applications
  are inevitably introduced.  These must be implemented while presenting the
  user with a way of working the system that is as easy to learn and adapt to
  as possible, both for the user's sake (for better user adoption) and for the
  organisation's (in less "down time" while learning the system). This applies
  not only to existing users: to expand the use of the PC and bring in more
  users, to make it a truly business system, barriers to learning the system
  must be lowered.

o Easily managed: put simply, the costs of installation, integration,
  maintenance and updates most not exceed the benefits of running the system.

o Investment protection:  all of these aims must be achieved without completely
  starting from scratch.  To retain users' comfort and capitalise on the
  existing investment in applications and hardware, maximum use must be made of
  the systems and applications in place, where possible integrating them with
  the new systems. But the design of such a system should offer compatibility,
  but not be constrained by the past. Investment exploitation is as important
  as protection in the long term.

All in all, the requirements of the PC systems of the 90s can be summed up in
one word: integration. The means of integration will be software, and in
particular the operating environment.  Once the basis is there, applications to
exploit it will follow.  In short, an advanced operating system is needed for
the PC of the 1990s, one that can exploit the benefits of the ten years' worth
of productivity applications, while moving the PC platform forward to address
the needs of the 1990s and become a "business" machine, rather than just a
productivity tool.


ΓòÉΓòÉΓòÉ 4.2. Cheaper processors and memory ΓòÉΓòÉΓòÉ

Some of the obstacles to the widespread use of an advanced platform, such as
high memory costs and insufficient processor capacity, are now being removed.
Memory prices have fallen dramatically over the last three or four years, and
the recent development of the 16 megabit DRAM chip means that memory is being
packaged in ever larger units (4MB or in future 8MB at a time).  This will
continue the rise in the average amount of memory installed in PCs:  in 1992,
nearly all IBM PS/2s using an Intel i386SX processor or above, ship with at
least 4MB of memory installed as standard, and nearly all other PC vendors are
doing the same.  Indeed, 8MB is no longer an unusual configuration, and many
high end machines can be installed with 16 and even 32MB of memory.

Furthermore, processor power is increasing rapidly, and Intel's i386 processor
family (i386SX and i386DX) has become the largest volume Intel processor
shipped in PCs.  According to industry estimates, in 1991, the majority of new
PC shipments had a 386SX or above, and by the mid-1990s this figure will
increase to over 90% as the i486 ships in greater volume. In fact, recent
changes in the competitive microprocessor market, have led to large reductions
in prices on even 486 chips, particularly the 486SX, so that some vendors are
even using the 486SX as the mainstream processor across their product range.
Therefore, 32-bit processors, whether 386 or 486, completely dominate new
shipments of PCs.

The result of this is that the new PCs shipped have a minimum of a 386SX and
4MB of memory, and commonly a 486SX and perhaps 8MB.  This enables
substantially more to be done with the PC platform and, in particular, an
advanced operating system base that can really begin to fulfil the PC's
potential.


Processor shipments and decreasing memory prices


ΓòÉΓòÉΓòÉ 4.3. OS/2 so far ΓòÉΓòÉΓòÉ

In the mid-1980s, IBM realised the need for an advanced platform, and saw that
single-tasking DOS was not likely to be able to meet these demands.  IBM
therefore set out with Microsoft to develop OS/2.  In 1987, the first
character-based version, OS/2 1.0 appeared, followed by the inclusion of the
Presentation Manager GUI in Version 1.1 (1988), and by Version 1.2 in 1989.
These were all based on the Intel 80286 (286) processor's protected mode, and
were therefore 16-bit releases.  Intel 386-based machines were supported, but
their full 32-bit potential was not exploited because of the requirement to
support the large base of 286 machines at the time.

These first releases provided the basis for a "platform of the 1990s", but the
learning curve involved in providing the operating system function itself and
in developing applications to exploit it, proved a greater challenge than
expected.

In 1990, IBM took over chief responsibility for the 16-bit versions of OS/2,
and later that year, produced Version 1.3, which has become a widely used
platform among companies who are beginning to develop in-house
"line-of-business" applications, benefiting from its multi-tasking, large
memory, industrial strength robustness and protection between processes. In
addition, 1.3 provided these capabilities with lower memory requirements than
previous releases, while adding extra features such as high quality font
support via the built-in Adobe Type Manager.

Although OS/2 1.3 has been highly regarded as a platform for line-of-business
applications, limits in the capability of the 286 processor set bounds on what
could be achieved in terms of compatibility with the existing range of DOS
productivity applications. This, in turn, placed limits on the level of
integration between new applications and the existing, extensive installed base
of DOS applications.

OS/2 2.0, which first shipped in March 1992, has been designed to build on the
strengths of OS/2 1.3, such as multi-tasking and threading, robust protection
between applications, and large memory support.  It adds to those facilities,
greater compatibility with the existing installed base of DOS and Windows
applications, so that users can choose from the widest range of applications on
an Intel-based platform.  Because it is designed for 32-bit processors like the
386 and 486, it can escape the limitations of the 286, and provide not only a
better platform for supporting old applications, but a new foundation for
32-bit applications which can fully exploit the capabilities of the 32-bit
hardware.  That is why OS/2 2.0 is the Integrating Platform, bringing together
the investments of the past, and providing a base for the future.


ΓòÉΓòÉΓòÉ 5. Why OS/2? ΓòÉΓòÉΓòÉ

This section summarises the reasons why OS/2 is the platform of choice for the
1990s:


ΓòÉΓòÉΓòÉ 5.1. The best of both worlds ΓòÉΓòÉΓòÉ

In the PC environment of the 90s, where both personal productivity and
line-of-business applications are required, only OS/2 can satisfy both needs.
It provides a better platform for DOS applications than DOS itself, and runs
the widest range of DOS and Windows applications, as well as being the best
platform for running in-house mission critical applications, with its
industrial strength, robust protection, and powerful multi-tasking.  You don't
have to choose between different systems for your different needs - OS/2 can do
both.


ΓòÉΓòÉΓòÉ 5.2. Broad appeal ΓòÉΓòÉΓòÉ

OS/2 2.0 is, therefore, a platform of broad appeal, not just for high end
usage, or for niche applications like servers, but as a client system, and a
productivity machine.  You do not need to be a "power user" to appreciate the
benefit of running several DOS and Windows applications on a reliable base. Not
only the features of the product, and the applications it can run, but its
price and the breadth of PC systems it can run on, have been planned to address
the widest possible audience of PC users. And this has already been proved to
be true. On August 12th, 1992, IBM announced that it had shipped one million
copies of OS/2 2.0 since its initial shipment in March. This represents,
according to data from independent estimates, an initial success comparable to
that claimed for DOS/Windows 3.0 in 1990.

During the first ten years of the PC, users, IS staff, and developers found it
difficult to arrive at a common platform: DOS and Windows satisfied the users's
needs for productivity applications, but lacked the reliability and full
connectivity support to be trusted in mission-critical environments by IS staff
and developers, whose systems remained mostly on the mini and mainframe.
However, OS/2 2.0 is a platform that can appeal to all three communities; the
right choice for the IS strategy, can now also be the platform that developers
and users can choose for themselves.


ΓòÉΓòÉΓòÉ 5.3. Freedom of choice ΓòÉΓòÉΓòÉ

Today's computing environment can be confusing: the sheer variety of options
can be overwhelming. And in making choices about hardware and software
platforms, it is difficult to follow a path which keeps a wide range of options
open. Too often choices can be constrained by compatibility issues or by a
limited growth path. OS/2 2.0 aims to simplify the decision by providing a free
choice: the widest range of applications on a wide range of hardware.

OS/2 2.0 can run DOS, Windows and OS/2 16-bit applications; it provides the
widest choice of applications on an Intel-based platform. More and more 32-bit
OS/2 applications are appearing, making the choice even greater. In fact, OS/2
2.0 is such a good environment for DOS and Windows applications, that even if
you only use DOS applications on a 386-based machine, OS/2 2.0 is the best
environment to run them in.

Furthermore, all applications running under OS/2 2.0, whether DOS, Windows or
OS/2 applications, gain added value from working together; they can share
information and be run from the common Workplace Shell desktop.  This not only
protects your current investment in DOS, Windows and OS/2 applications, but
adds value to them by integrating them together.

OS/2 2.0, and Extended Services and OS/2 LAN Server, are supported on a wide
range of IBM-compatible hardware as well as IBM PS/2s. This means you can run
OS/2 with confidence on hundreds of machines from vendors including Compaq,
Olivetti, Dell, Hewlett Packard and Toshiba, and with IBM support.  In fact,
even though IBM cannot test OS/2 on all the models and manufacturers in the
market, it is likely that most PCs equipped with an Intel 386SX or above
processor, will work.


ΓòÉΓòÉΓòÉ 5.4. A productive environment for the user ΓòÉΓòÉΓòÉ

OS/2 provides an object-oriented user interface, the Workplace Shell, which
allows users to think of the information they want to work with, not think
first of what application needs to be loaded.  This is a business-oriented,
rather than computer-oriented way of working.  In this way, users become more
productive. They can concentrate more on what they want to do, and less on how
to do it.  The Workplace Shell also provides a single, consistent environment
in which multiple applications can be loaded from different sources.  It is an
easy environment to learn, since once you know how to drag a file's icon with
the mouse to put it into a folder, you can use the same operation to print it,
and to copy it to another disk or folder.  In addition, companies can benefit
from a standard interface, which complies with IBM's Common User Access (CUA)
definition for user interface design.

Also, since many applications can be loaded and running at the same time, users
can be more productive, especially in work that involves much interruption and
switching from one task to another.  OS/2's true multi-tasking means that
long-running processes can simply be switched to the background, while the user
continues with something else.  This results in less "wait time"  for the user.
At the same time, more can be done with the existing set of applications by
allowing them to share information easily via consistent interfaces like the
clipboard.


ΓòÉΓòÉΓòÉ 5.5. Better DOS, Windows and OS/2 ΓòÉΓòÉΓòÉ

OS/2 2.0 doesn't just run the widest range of applications on an Intel
platform. It also aims to improve even on the native environment of each
application, and provide a better environment for that application to work in:


ΓòÉΓòÉΓòÉ 5.5.1. A better DOS ΓòÉΓòÉΓòÉ

it adds to the DOS environment: multi-tasking, more memory and application
integration (see  Better DOS ).


ΓòÉΓòÉΓòÉ 5.5.2. A better Windows ΓòÉΓòÉΓòÉ

it provides a superior environment for running DOS applications than either
Windows 3.0 or Windows 3.1, and also runs a wide range of Windows applications
with no loss of function, as well as taking advantage of the better
multi-tasking, memory support, and reliability of OS/2 (see Better Windows ).


ΓòÉΓòÉΓòÉ 5.5.3. A better OS/2 ΓòÉΓòÉΓòÉ

it improves even on previous releases of OS/2 itself, providing a new
object-oriented user interface, a graphical install program, and access to
powerful 32-bit applications (see Better OS/2 ).


ΓòÉΓòÉΓòÉ 5.6. A platform you can rely on ΓòÉΓòÉΓòÉ

When the PC becomes the focal point of information processing, as in today's
environment it often is, then the PC platform must show the stability and
reliability of the host environment. The main reason why the PC has not been
trusted to fulfil this crucial role to date, is because its operating system -
DOS - was not designed for "mission critical" use, but as a personal
productivity environment. Nor can extensions to DOS such as Microsoft Windows,
offer the required stability while they continue to be based on DOS. Only OS/2,
which has been designed to protect applications from one another, can deliver
the stable platform required for full multi-tasking and greater protection from
system crashes. It is no use having the most fault tolerant server or host, if
the client keeps going down. And even the productivity user's PC is "mission
critical" from that user's perspective, so that reliability is a requirement
for every PC.


ΓòÉΓòÉΓòÉ 5.7. Superior connectivity ΓòÉΓòÉΓòÉ

OS/2 2.0 is both the server and the client platform of choice.  Its strong
multi-tasking and robust protection make it the best available base for working
in a connected environment, in client-server and distributed processing.  It
provides a consistent platform for both server and client, can handle multiple
concurrent communications protocols (eg NETBIOS, APPC, IPX, TCP/IP) with ease,
and even provides a LAN-independent user interface to mixed vendor networks. It
is enabled for automated LAN-based installation.  But most important, OS/2
offers the stability and reliability in a client to match the reliability of
the server or host. The result is that "mission critical" applications which
depend on communications with various systems can be implemented much more
safely on OS/2 than on DOS or any of its extensions.

OS/2 2.0 is also the base system for a family of networking and communications
products from IBM, including Extended Services for OS/2 and OS/2 LAN Server.

Extended Services for OS/2 provides powerful communications and database
function in a single integrated package.  It supports multiple communications
protocols (EHLLAPI, NETBIOS, APPC, X.25 and asynchronous) and terminal
emulators (3270, 5250, ASCII, VT100).  It includes a full function
client-server relational database management system (RDBMS).  This RDBMS is
part of an SAA family of relational databases which also includes DB2 and
SQL/DS.  Extended Services for OS/2 also includes query and database management
tools.

OS/2 LAN Server works with OS/2 to provide Local Area Network support to DOS
and OS/2 machines. It includes facilities for sharing resources such as files
and printers, and to manage those shared resources, providing security control,
applications management, and network statistics.

Both Extended Services for OS/2 and OS/2 LAN Server 2.0 run on both OS/2 2.0
32-bit and the 16-bit OS/2 1.3.1 bases.  OS/2 LAN Server 3.0 runs only on the
OS/2 2.0 base.  Both Extended Services for OS/2 and OS/2 LAN Server are also
supported on selected non-IBM as well as IBM equipment.  More details on these
and other networking products are available in the chapter on OS/2 in a
connected environment (see OS/2 in a connected environment ).


ΓòÉΓòÉΓòÉ 5.8. The integrated system ΓòÉΓòÉΓòÉ

OS/2 not only makes DOS, Windows and OS/2 applications run together, but also
provides a GUI, and, with Extended Services for OS/2 and LAN Server, database,
communications, and LAN support.  For developers, all the Application
Programming Interfaces (APIs) and services have been designed to work together.
This means customers don't have to do the systems integration work with a
variety of DOS-based packages to include all the function required, and work
around any incompatibilities or problems.  Instead, the OS/2 function has been
designed and tested to work together - IBM has already done the integration
work.

OS/2 also has advanced features built in and integrated with the rest of the
system: the Presentation Manager GUI itself, font handling with Adobe Type
Manager (ATM) (now for both OS/2 applications and Windows applications), REXX
(the extended batch language which can be used to integrate different
applications and automate common routines)

The Workplace Shell environment integrates DOS, Windows and OS/2 applications
and makes them work together, even though they may have been written by
different vendors and never designed to do so.  Also, OS/2 can permit working
combinations (such as a 32-bit OS/2 word processor and a 16-bit DOS
spreadsheet) that would never have been possible before.  In summary, the whole
is greater than the sum of the parts:  in running not only OS/2, but DOS and
Windows applications, OS/2 makes them work together from the same user
interface.  This helps reduce the differences between applications, and between
the local machine and the network, and make it all act as one system. That's
why OS/2 is the integrating platform.


ΓòÉΓòÉΓòÉ 5.9. 32-bit power ΓòÉΓòÉΓòÉ

OS/2 2.0 is the first mainstream 32-bit platform for Intel-based PCs. It offers
the ability to take full advantage of the performance of today's 32-bit PCs.
And over over 1000 32-bit OS/2 applications are being developed (several
hundred of which had already shipped by September 1992), to demonstrate what
can be achieved with a 32-bit system.

The OS/2 32-bit API also allows developers to create richer, more sophisticated
applications.  It overcomes the constraints imposed by existing 16-bit systems
(see Why 32-bit OS/2? ).  This allows applications like multimedia to exploit
their full potential and power.  OS/2 provides this foundation today.  Moving
to the OS/2 32-bit API now, gets developers ready for future developments in
OS/2, such as object-oriented technology, distributed computing and portability
to RISC.  So 32-bit is not just about exploiting the power of today's
environments, but also to move forward to build for the future.  But most of
all, OS/2 2.0 gives you the benefits of a 32-bit system NOW - no need to wait
for other alternatives with uncertain delivery dates.


ΓòÉΓòÉΓòÉ 5.10. Platform for growth ΓòÉΓòÉΓòÉ

The design of OS/2 not only preserves the investments of the past, but allows
maximum flexibility for future growth. It also makes the OS/2 system itself
ready to develop further (for portability to other processors, for example).

OS/2 will be the base of new developments for many of the features that will be
a requirement for the workstation of the mid-90's, such as multimedia,
object-oriented systems, support for the Distributed Computing Environment
(DCE) and portability across different processors. It has the extra power to
support such advanced features as they emerge.  Requirements of this kind will
demand a robust, architected and powerful 32-bit system, and that system is
OS/2.

With OS/2 2.0, IBM has reaffirmed its commitment to OS/2, and its conviction
that the workstation of the 1990s requires a real advanced platform, not a
series of extensions to DOS, which is fundamentally ill-equipped for these
requirements.


ΓòÉΓòÉΓòÉ 5.11. Value for money ΓòÉΓòÉΓòÉ

OS/2 2.0 offers a "3 in 1" environment, with everything you need to run DOS,
Windows and OS/2 applications in the one package.  It also includes a series of
productivity applications, utilities and games for which you need to pay extra
in the DOS world.  OS/2 provides scalable font support for both Windows and
OS/2 applications with Adobe Type Manager at no extra charge. OS/2 2.0 offers
all this function at a price less than the combined cost of DOS and Windows
3.1, even before taking into account the extra utilities you would need to buy
under DOS or Windows to achieve the same function. Upgrading from DOS or
Windows makes the cost of moving to OS/2 even less.


ΓòÉΓòÉΓòÉ 5.12. Exploits today's investment, and is a base for the future ΓòÉΓòÉΓòÉ

OS/2 supports the widest choice of applications from the past ten years of the
PC, and is the best platform for the present requirement of client-server and
reliable connectivity. It also provides the best base for future technologies.
That's how OS/2 2.0 can integrate past, present and future requirements. It
already has NOW what other environments can only promise for the future, with
the best and most reliable migration path - why wait?


ΓòÉΓòÉΓòÉ 6. OS/2 2.0 key elements ΓòÉΓòÉΓòÉ

This section examines some of the key technologies and features of OS/2 2.0,
which affect all applications running in the system.  The following sections
cover OS/2 from an application point of view, showing how it exceeds the
capabilities of DOS, Windows 3.x and previous releases of OS/2.


ΓòÉΓòÉΓòÉ 6.1. 32-bit ΓòÉΓòÉΓòÉ

OS/2 2.0 is the first version of OS/2 to support a 32-bit addressing system and
programming model.  Although implemented on the Intel 386 and 486 family of
processors, it is really a 32-bit system rather than an Intel-specific system.
Mike Kogan, one of the lead designers of 32-bit OS/2 has said in his book The
Design of OS/2 2.0 (see Further reference materials ), "OS/2 2.0 was not
designed to be 386-specific, but rather 32-bit OS/2 implemented on the 80386
platform".  Part of the design of OS/2 2.0 has been to leave the maximum
possible scope for future portability, both in the API and the subsystems like
Presentation Manager (PM).

OS/2 2.0's 32-bit design provides significant benefits to the user and the
programmer, including better performance, simpler programming and ease of
migration from 16-bit applications, as well as reinforcing the benefits of
inter-process protection associated with previous releases of OS/2.


ΓòÉΓòÉΓòÉ 6.1.1. Flat memory model ΓòÉΓòÉΓòÉ

OS/2 2.0 features a different memory addressing model from 1.3 - the flat
memory model. This enables each process to look at memory as a large linear
address space which can be addressed by a simple 32-bit offset (sometimes
referred to as "0:32"), as opposed to the segment/offset combination ("16:16")
required by OS/2 1.3 and other 16-bit systems like DOS and Windows. The 0:32
model therefore hides all details of segmented memory management from the
32-bit programmer, resulting in :

- much simpler programming
- better performing code
- greater portability to other instruction sets (ie non-Intel).

One example of better performance is in calling Dynamic Link Libraries (DLLs),
which are common in both the OS/2 system and OS/2 applications. Since all code
and data are addressable within the same linear address space, there is no
longer any need for segment switching.


ΓòÉΓòÉΓòÉ 6.1.2. Large memory address space ΓòÉΓòÉΓòÉ

Using the 32-bit flat memory model, the 386 processor supports up to a 4
gigabytes (GB) linear address space.  In fact, up to 64 terabytes can be
addressed by the processor using a non-linear addressing model.  To get some
idea of the enormity of such numbers, this means that, if an average page in a
book contained 2000 characters, and each book 500 pages, a task could address
any character in any book in a library with more than 70 million books
(70,368,744,177,664 characters to be precise)!

For reasons of compatibility with OS/2 1.x 16-bit applications, the address
space per process in OS/2 2.0 is restricted to 512MB (since this is the maximum
address space possible for 16:16 applications).  This is addressed using the
flat memory model, allowing programmers to reference memory under OS/2 2.0 as
one single huge address space.  Although 512MB is hardly likely to be a
limitation in practice, this memory limit will be removed in a future release
of OS/2.

Within a given process, memory objects can be allocated for any size, no longer
limited to the 64KB segment maximum, but any size between 1 byte and 512MB.
This gives the programmer much greater flexibility in memory management.  For
the user, this means that programmers can spend more time on making their
programs more powerful and even easier to use, and less on segmented memory
management.


ΓòÉΓòÉΓòÉ 6.1.3. Virtual memory ΓòÉΓòÉΓòÉ

OS/2 2.0 can use more memory than is physically installed in most PCs, by using
the hard disk for additional memory, usually referred to as virtual memory.
Although 16-bit systems like OS/2 1.3 and Windows 3.x also offer memory
overcommit via swapping segments to disk, the larger process address space
available under OS/2 2.0 means that virtual memory is effectively limited only
to available disk space, whereas Windows 3.x can offer only 16MB maximum, or
four times the physical memory installed in the machine, whichever is less.
OS/2 2.0 takes advantage of the 386 processor's support for fast and effective
paging of memory to and from disk (see 4KB demand paging ).  It is also not
limited to the segment-based swapping of OS/2 1.3.


ΓòÉΓòÉΓòÉ 6.1.4. Mixed 16-/32-bit environment ΓòÉΓòÉΓòÉ

Not only are OS/2 1.x applications supported, and are binary-compatible with
2.0, but OS/2 2.0 can support mixed model programming. In order to support
applications written for 16-bit, the OS/2 designers had to develop an
architecture in which 16- and 32-bit modules could reside simultaneously. This
was not only for ease of conversion from 16-bit programs, but also because the
system itself contains a mixture of 16- and 32-bit service routines.  This is a
difficult task because segmented and flat memory models are so different.

OS/2 provides address conversion between 16:16 and 0:32 addresses, to allow
16-bit API calls to be serviced internally by 32-bit routines, and vice versa.
A series of procedures called "thunks"  within the system facilitate this
process, by handling any necessary parameter conversion for APIs.  This
technique is used internally between 16- and 32-bit parts of the system itself,
but the user never notices - the system takes care of it.  They are tools
internal to the system, and not APIs for the programmer to learn and use - and
certainly no user needs to know how to handle them.

Note that the mixed model gives great flexibility, both in migrating
applications from 16- to 32-bit, and also in allowing 32-bit applications to
make the best possible use of existing 16-bit service routines, window classes
etc., developed for previous releases of OS/2. The important point here is how
OS/2 2.0 helps the migration process to 32-bit.


ΓòÉΓòÉΓòÉ 6.2. Intel 386/486 exploitation ΓòÉΓòÉΓòÉ

Since OS/2 2.0's 32-bit capabilities are implemented on Intel's i386 and  i486
family of processors, it is not surprising that the system takes advantage of
some of the processor's features.  Indeed, some of them (especially virtual
8086 mode) are vital to some of the most notable features of the system.  It is
for that reason that OS/2 2.0 requires a 386SX processor or higher to run.
Unlike OS/2 1.3, it will not run on machines equipped with an 80286, nor will
it run on 8088 and 8086 machines supported by DOS.


ΓòÉΓòÉΓòÉ 6.2.1. Growth in processor power ΓòÉΓòÉΓòÉ

It is widely recognised how substantial have been the improvements in processor
speed and capacity, even since 1981 and the launch of the first IBM PC. Since
then, processor clock speed has increased by a factor of seven, and memory
address space by four thousand to one.  This growth in processor power lowers
the cost of the hardware technology to run advanced operating systems and
applications.  The software and hardware are now at a sufficiently advanced
stage, to enter a new phase of personal computing, beyond the basic
productivity applications that have characterised its usage to date (see
Cheaper processors and memory ).


ΓòÉΓòÉΓòÉ 6.2.2. 386/486 now majority of shipments ΓòÉΓòÉΓòÉ

PCs using the i386 family (which includes the SX as well as DX models) are now
shipping in greater volumes than any other Intel processor.  Add to the number
of 386s the growing volumes in 486SX and DX processors, and there are a growing
number of 32-bit processors in the marketplace.  Until OS/2 2.0, there has not
been a 32-bit system for Intel processors which has provided sufficient
compatibility with existing 16-bit applications, to become a standard.


ΓòÉΓòÉΓòÉ 6.2.3. 386SX versus DX ΓòÉΓòÉΓòÉ

It is important to understand that both 386SX and 386DX processors are
supported by OS/2. Even though the 386SX has a 16-bit external data bus, it is
a 32-bit processor internally, fully compatible with the 386DX processor's
instruction set, supporting multiple Virtual 8086 sessions (essential for the
Multiple Virtual DOS Machines features of OS/2 2.0), protected mode operation
and full 32-bit addressing.  It can therefore support all of the features that
OS/2 2.0 provides, just as the 386DX does.  The main difference is in the
throughput for I/O, owing to the 16-bit data bus.  Nevertheless, many users
find it an excellent combination of 386 function, compatibility and performance
at a reasonable price.  IBM's own 386SLC chip, which appears in, among others,
some models of the PS/2 Model 57, adds performance features such as caching to
the basic 386SX design; it represents an excellent platform for OS/2 2.0.


ΓòÉΓòÉΓòÉ 6.2.4. 486SX and DX ΓòÉΓòÉΓòÉ

All the 386 features used by OS/2 2.0 are also supported by the 486. Therefore
machines using a 486SX or 486DX will also run OS/2 2.0. In many operations, the
486 is faster than the 386, which will provide performance benefits to users of
OS/2 2.0 on 486-based machines. The 486SX is very similar to the 486DX, but
does not have the built-in math co-processor function which the 486DX has. The
price of the 486SX processor has fallen rapidly during 1992, so that machines
using 486SX can often be obtained at prices competitive with 386DX machines.
The 486SX therefore represents an economical entry into 486 power for OS/2 2.0.


ΓòÉΓòÉΓòÉ 6.2.5. Features of 386 chip used by OS/2 2.0 ΓòÉΓòÉΓòÉ

Among the specific features of the 386/486 processors supported by OS/2 2.0,
and used to provide additional function beyond OS/2 1.3, are:

Protected mode operation
Virtual 8086 mode
4KB demand paging
Numeric co-processor support


ΓòÉΓòÉΓòÉ 6.2.5.1. Protected mode operation ΓòÉΓòÉΓòÉ

To understand the significance of protected mode, let us briefly review some of
the different models of memory management which the 386 processor can use:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé          Memory management models                              Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé MODEL    Γöé PROCESSORΓöé MAX      Γöé ADDRESSINΓöé PRO-     Γöé SYSTEM  Γöé
Γöé          Γöé ARCHI-   Γöé PHYSICAL Γöé STYLE    Γöé TECTION  Γöé SOFT-   Γöé
Γöé          Γöé TECTURE  Γöé ADDRESS  Γöé (SEG-    Γöé BETWEEN  Γöé WARE    Γöé
Γöé          Γöé          Γöé SPACE    Γöé MENTED   Γöé PROC-    Γöé EXAMPLE Γöé
Γöé          Γöé          Γöé          Γöé VS.      Γöé ESSES    Γöé         Γöé
Γöé          Γöé          Γöé          Γöé FLAT)    Γöé          Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Real     Γöé 8086     Γöé 1MB      Γöé seg-     Γöé none     Γöé DOS     Γöé
Γöé mode     Γöé          Γöé          Γöé mented   Γöé          Γöé         Γöé
Γöé          Γöé          Γöé          Γöé (64KB)   Γöé          Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Seg-     Γöé 80286    Γöé (on 286) Γöé seg-     Γöé yes      Γöé OS/2    Γöé
Γöé mented   Γöé          Γöé 16MB     Γöé mented   Γöé          Γöé 1.3,    Γöé
Γöé Memory   Γöé          Γöé          Γöé (64KB)   Γöé          Γöé Windows Γöé
Γöé Model    Γöé          Γöé          Γöé          Γöé          Γöé 3.x     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Flat     Γöé i386     Γöé 4GB      Γöé flat     Γöé yes      Γöé OS/2    Γöé
Γöé Memory   Γöé          Γöé (16MB on Γöé          Γöé          Γöé 2.0     Γöé
Γöé Model    Γöé          Γöé 386SX)   Γöé          Γöé          Γöé         Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

In reality, operating systems like OS/2 create an architecture with indirect
selectors/descriptors rather than direct segment/offset addressing. This
provides memory protection between processes to support multi-tasking. This is
just one example of the ways in which an operating system builds on the base
capabilities of the processor. Virtual memory is another function provided by
the operating system but relying on a processor feature (in this case on the
286 and above).

In OS/2, all process address spaces are kept separate from each other. This
allows OS/2 to maintain protection between different processes running in the
system, whether they be DOS, Windows or OS/2 applications, or other parts of
the system itself. The result is that, if a process attempts to reference
memory outside its own address space, it is trapped by the system. In contrast,
multi-tasking systems based on single-tasking DOS, such as Windows, cannot
always offer protection.  Windows applications, for example, share the same
Local Descriptor Table as Windows itself, which limits the memory protection
Windows can provide to its applications (see Reliability and  Reliability and
protection ).


ΓòÉΓòÉΓòÉ 6.2.5.2. Virtual 8086 mode ΓòÉΓòÉΓòÉ

The 386 offers a mode called virtual 8086 (V8086) mode, which emulates multiple
instances of an Intel 8086 processor to provide some compatibility with real
mode applications (such as most DOS applications) under a protected mode system
(like OS/2 2.0).  Applications running in V8086 mode, can run concurrently with
other 8086 applications and protected mode applications, and take advantage of
the virtual memory and paging facilities of the 386.  V8086 mode is a superset
of protected mode.

The CPU provides high performance hardware support to enable switching between
V8086 and protected mode - this eliminates the performance overhead of mode
switching associated with lower processors such as the 286. This is why
multiple DOS capability can be provided so much more easily and more
effectively in OS/2 2.0, which requires the 386 facilities, than in OS/2 1.3
which was based on a 286-style architecture.

V8086 processes are protected from each other in OS/2 2.0. This gives
compatibility with the real mode world of DOS applications while providing
greater address space and protection. In OS/2 2.0, each Virtual DOS Machine
(VDM) is encapsulated in its own unique linear address space, and thus cannot
corrupt another application's code or data.  Traps or exceptions are handled by
the VDM Manager in OS/2 2.0, and execution is passed to an exception handler,
or the VDM terminated.  Therefore, OS/2 2.0 runs in protected mode all time,
even for DOS applications, hence the greater protection of the system against
application errors or failures.

In real mode, an application can directly address any object in memory between
0 and 1MB, including portions of the operating system (whether this be DOS,
DOS/Windows, or OS/2 1.3, all of which provide varying amounts of real mode
execution).  A DOS program that accidentally wrote to a system area, or
directly addressed a hardware device and left it in an unknown state, could
cause system integrity problems.  Real mode is less of an issue in a
single-tasking system like DOS, where it is more than likely that the
application is the only one executing in the system; but in a multi-tasking
system, it represents a "trap door", which can endanger system integrity. This
is part of the difficulty in running a multi-DOS environment like Windows 3.0
or 3.1 on a DOS base; as long as there is real mode access (as long as it runs
on DOS as we know it today), there is a potential risk.  In fact, even Windows
3.1 , which is claimed to offer greater protection and stability, does not
change the design of Windows in this respect.  It is still possible for a DOS
Terminate-and-Stay-Resident (TSR) program to switch the system into real mode
and open up the potential for endangering system integrity (see Reliability for
more on this).

The only solution is to run the operating system in protected mode, and provide
a multi-DOS mode using features like V8086, so that the system never runs in
real mode.  This is exactly what OS/2 2.0 does, and it is one of the key
differences between it and Windows 3.x in terms of overall integrity: Windows
implements V8086 function in a system running on DOS, and some real mode access
is inevitable - hence its occasional fragility when working with DOS
applications or TSRs; OS/2 2.0 never executes in real mode.


ΓòÉΓòÉΓòÉ 6.2.5.3. 4KB demand paging ΓòÉΓòÉΓòÉ

Demand paging is the 386's method of providing virtual memory to the system;
when physical memory is exhausted (memory "overcommitment"), the disk may be
used to provide additional virtual memory. Memory overcommit is provided on
286-based operating systems such as OS/2 1.3 as well, but is usually based on a
segment-swapping mechanism. As the name suggests, segment swapping is closely
tied to the segmented model used in OS/2 1.3, and the swapper algorithm has to
do much work to compact segments of varying sizes into a unit capable of being
swapped to disk, or much I/O work in swapping large segments.

OS/2 2.0 manages memory internally using pages, each of which is 4KB in size.
Each memory object handled by the system is regarded as a set of one or more
pages, and therefore memory is allocated in units of 4KB (although to optimise
memory management, programmers may handle a page as multiple smaller objects).
Paging offers a number of advantages over swapping, which was the mechanism
used in OS/2 1.3:

Better granularity: when memory becomes over-committed (ie there is no more
real memory left to load applications), individual 4KB pages may be swapped to
and from disk, rather than entire memory objects (or segments as in OS/2 1.x).
In turn, this will improve performance, especially in terms of the lower I/O
cost of moving 4KB pages as opposed to whole segments.

Programmers can write their applications to take advantage of the smaller
granularity of memory object (ie 4KB page as opposed to a whole segment). This
will reduce the working set (overall memory usage) of applications and thence
improve performance. Memory objects can be allocated in logical units, without
the artificial constraints of segment sizes; this means that you can allocate
smaller or larger memory objects according to the needs of the application,
rather than the constraints of the system. Once again, this makes programming
much simpler.

It is important to remember that paging is carried out without any awareness on
the part of the application.  Programmers may allocate memory to co-operate
with this mechanism for performance reasons, but the user need not be aware of
the paging system at all.  It will simply translate into the performance
benefits mentioned above.

Simpler swap algorithm: because of the more granular paging, OS/2 2.0 does not
need to move around different sized segments to compact them into a single swap
segment of the right size, as was done in 1.x.  This makes the swap algorithm
simpler and therefore faster, improving overall system performance.  Indeed,
unlike OS/2 1.x, the swapper file, SWAPPER.DAT is designed to actually shrink
as well as grow during use of OS/2 2.0.  This is in order that applications
requiring high availability (such as LAN servers) do not need to be rebooted to
recover swap disk space.

The 386 has hardware support, such as buffering and caching, to support paging.
Once again, OS/2 is taking advantage of the processor's built-in features.


ΓòÉΓòÉΓòÉ 6.2.5.4. Numeric co-processor support ΓòÉΓòÉΓòÉ

Some OS/2 applications can make use of an i387 numeric co-processor if one is
installed in a 386 PC running OS/2 2.0 (or 486DX systems, which have
co-processor function built in).  Where a 387 is not installed, OS/2 2.0
provides a 387 emulator to all applications running in protected mode,
available to both 32-bit and 16-bit applications, but not VDMs running DOS
applications.  DOS applications must continue to use whatever mechanisms they
are currently using to detect co-processor presence.


ΓòÉΓòÉΓòÉ 6.3. Multiple Virtual DOS Machines (MVDM) ΓòÉΓòÉΓòÉ

OS/2 2.0 features a totally redesigned environment for DOS compatibility. It is
based on the Virtual 8086 mode of the 386 processor, and results in a DOS
environment where multiple DOS applications can be run, each in their own
separate "virtual machine". "Virtual machine" means that the virtual 8086 mode
process simulates a self-contained DOS environment, in which the application
runs. Access to I/O resources is usually not done directly to the physical
device, but via a virtual device; this virtualisation allows the DOS
application to believe it owns all the system resources, just as it does under
DOS.  Behind the scenes, the OS/2 system manages concurrent access to these
physical resources, from both DOS and OS/2 applications.

Each Virtual DOS Machine, or VDM, emulates an entirely independent instance of
DOS.  It is in fact a generic emulated version of DOS (which resembles DOS
5.0), not the real DOS retail product.  Each VDM is a separate process,
protected from the others, and multi-tasking alongside the others.  This design
allows OS/2 to provide superior support for DOS applications than in previous
releases of OS/2.


ΓòÉΓòÉΓòÉ 6.3.1. Contrast with OS/2 1.3 DOS support ΓòÉΓòÉΓòÉ

It is useful to look at the OS/2 2.0 DOS support in the light of 1.3's DOS
support. The following table gives a summary of the key difference in DOS
support between 1.3 and 2.0:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 2. DOS environments - OS/2 1.3 and 2.0 compared          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                           Γöé OS/2 1.3         Γöé OS/2 2.0        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Processor mode            Γöé Real mode        Γöé V8086 mode      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Protection/Integrity      Γöé Low              Γöé High            Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Number of DOS applica-    Γöé 1                Γöé up to 12 full   Γöé
Γöé tions                     Γöé                  Γöé screen; up to   Γöé
Γöé                           Γöé                  Γöé 240 windowed    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Background execution      Γöé No               Γöé Yes             Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Windowed                  Γöé No               Γöé Yes             Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Cut and Paste             Γöé No               Γöé Yes             Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Conventional memory free  Γöé 512KB            Γöé 633KB           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DOS Extended Memory       Γöé None             Γöé 16MB per appli- Γöé
Γöé                           Γöé                  Γöé cation (XMS)    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé EMS/XMS                   Γöé No               Γöé Yes             Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DPMI                      Γöé No               Γöé Yes             Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Overcommit                Γöé Swap             Γöé Page - Avail-   Γöé
Γöé                           Γöé                  Γöé able disk       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Timing Dependent applica- Γöé Foreground       Γöé Foreground /    Γöé
Γöé tions                     Γöé                  Γöé Background      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Recover from hang/crash   Γöé Sometimes        Γöé Usually         Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

Let's take a look at some of these aspects in more detail:


ΓòÉΓòÉΓòÉ 6.3.1.1. 286-based architecture ΓòÉΓòÉΓòÉ

OS/2 1.3    On the 286, there is no V8086 mode, so 1.x had to run DOS
            applications in real mode, thus requiring a protect-to-real mode
            switch when moving from an OS/2 to DOS application. This involves
            significant performance degradation (see below).

OS/2 2.0    DOS applications run in V8086 mode. No protect-to-real mode
            switching is needed.


ΓòÉΓòÉΓòÉ 6.3.1.2. Relative performance ΓòÉΓòÉΓòÉ

OS/2 1.3    A switch from real mode to protected can be done on a 286 (though
            it costs many CPU cycles). A switch the other way, from protected
            to real, means effectively rebooting the CPU, but OS/2 has to
            preserve all the system control information, process states etc, at
            the same time, so that the normal processing can continue after the
            switch. This switching back and forth from real (DOS box) to
            protected (rest of 1.x) generates significant overhead. This can
            mean that OS/2 background tasks are slowed significantly when
            running a DOS application in the foreground.

OS/2 2.0    DOS applications run in V8086 mode. No protect-to-real mode
            switching is needed.


ΓòÉΓòÉΓòÉ 6.3.1.3. System integrity ΓòÉΓòÉΓòÉ

OS/2 1.3    Since 1.3 does not run always in protected mode (unlike 2.0), any
            switch into real mode allows an errant DOS application to directly
            address any object in memory under 1MB, including portions of the
            OS/2 1.x kernel (the same is true in Windows 3, hence its
            comparative lack of integrity.)

            Also, DOS applications could directly address a hardware device and
            leave it in an unknown state, which may cause OS/2 device drivers
            to fail.

            Either of these scenarios could cause the whole system to crash.

OS/2 2.0    All OS/2 2.0 processes, including DOS applications in VDMs, are
            protected from each other, and cannot write outside their own
            address space. Hardware access is controlled through Virtual Device
            Drivers (see Virtual Device Drivers (VDDs) ), which handle the
            DOS-OS/2 hardware concurrency problem.


ΓòÉΓòÉΓòÉ 6.3.1.4. Background execution ΓòÉΓòÉΓòÉ

OS/2 1.3    DOS applications are suspended when not in the foreground. This was
            a decision made in 1.x, mainly to avoid the overhead in
            real-protected-real mode switching; it means that timing dependent
            applications like communications programs are unsuitable for
            running in an OS/2 1.3 DOS box, as they cannot receive interrupts
            while suspended.

OS/2 2.0    In 2.0, the virtualisation of interrupts and hardware access allows
            most communications programs to run in background in a VDM.


ΓòÉΓòÉΓòÉ 6.3.1.5. Amount of memory ΓòÉΓòÉΓòÉ

OS/2 1.3    Since DOS applications run in real mode, some of the OS/2 device
            driver and kernel code has to be located below 1MB to service the
            real-mode (DOS box) requests. This has an inevitable result on the
            amount of memory available below 1MB, and therefore on DOS
            application space, which, in 1.3, depending on the configuration,
            is about 520KB.  This prevents some larger DOS applications from
            even loading.  No EMS or XMS support is provided in 1.3.

OS/2 2.0    OS/2 2.0 locates most driver and even DOS emulation code outside
            the DOS application's address space in a VDM. This provides even
            more conventional memory than under standalone DOS, and full
            support for EMS and XMS (see below).


ΓòÉΓòÉΓòÉ 6.3.2. Memory: Conventional, Expanded, Extended ΓòÉΓòÉΓòÉ

Memory management under DOS today is quite complex, and often requires the user
to know about various different memory types.  To support some DOS
applications, OS/2 2.0 needs to provide more than just conventional memory.


ΓòÉΓòÉΓòÉ 6.3.2.1. Definitions ΓòÉΓòÉΓòÉ

The diagram below shows some of the types of memory commonly referred to, and
is a useful reference for the discussion below:


Memory: Conventional, Expanded, Extended

Conventional memory  is the name given to the memory area up to 640KB
accessible by DOS applications.

Extended Memory refers to any memory above the 1MB line addressed by the
processor in protected mode.  (1MB is the normal limit addressable by the
processor in real mode).  The LIMA (Lotus/Intel/Microsoft/AST) Extended Memory
Specification (XMS) version 2.0 provides a standard for the use of extended
memory on 80286 and above computers.  The specification provides for moving
code and data objects to and from extended memory to base (conventional)
memory, and is operating system independent (even though the technique for
determining that XMS is present relies on the DOS interrupt vector 2Fh).  XMS
manages 3 different kinds of memory, described below:

-   High Memory Area (HMA)
-   Extended Memory Blocks (EMBs)
-   Upper Memory Blocks (UMBs)

High Memory Area (HMA) is the region of memory between 1MB and the 64KB above
it (minus 16 bytes).  This can be addressed by enabling one of the processor's
address lines to allow the processor to access an extra 64KB beyond the normal
1MB limit in real mode.  Its operation is due to an anomaly in the 286 and
above, which has been exploited by this technique to give a valuable extra
address space.  Drivers like HIMEM.SYS, which appear in DOS 5.0 and MS-Windows
3.x, exploit this technique.

Extended Memory Blocks (EMBs) are blocks of extended memory above the HMA, not
accessible from real mode and serve usually as data storage. An XMS driver can
move memory between extended and conventional memory to offer up to 64MB of
extended memory in up to 255 blocks.

UMA, UMBs: between 640KB and 1MB (the limit addressable by the processor in
real mode) lies the Upper Memory Area (UMA).  In this area are reserved
portions of memory for BIOS, video buffers etc.  Usually, however, there are a
number of address ranges not used (for example, since there are address ranges
for monochrome, CGA and EGA adapters, it is not possible to use all of these
ranges at the same time.  Thus there will be a number of "gaps"  in the UMA.
These can be used by memory managers such as exist in DOS 5.0 itself, or by
third party utilities such as Quarterdeck's QEMM product.  They can be used to
load various drivers, or in DOS 5.0's case, even part of the system itself, to
free more memory below the 640KB line.  The address ranges used in this manner
are usually called Upper Memory Blocks or UMBs.  The number and size of UMBs
will depend on the hardware configuration.

Expanded Memory (EMS) is a page mapping technique that provides additional
memory support, by allowing DOS applications to allocate and access up to 32MB
of additional memory.  This is done by creating memory objects in expanded
memory that can be mapped into the real mode 1MB address space, thus allowing
DOS applications to access address spaces beyond 640KB at the cost of having to
quickly remap the memory that is to be accessed.  In effect, parts of the 8086
address space become moving "windows"  into larger virtual memory objects in an
expanded memory area.  The expanded memory specification was developed by
Lotus, Intel and Microsoft, and is thus known as LIM EMS. The latest version of
the specification is 4.0.  EMS is provided under DOS either by a special memory
adapter and driver, or by defining portions of memory above 1MB for use as
expanded memory by a driver that sometimes ships with DOS (eg EMM386.EXE with
DOS 5.0).

DOS Protect Mode Interface (DPMI): The DPMI specification provides a standard
interface that can access memory above 1MB and is addressable by computers with
an Intel 80x86 (or later) microprocessor.  The specification was created by a
group of eleven companies in the industry (including Microsoft, Lotus and
Intel, as well as Quarterdeck, Rational Systems and Phar Lap), to allow
multiple DOS extender applications to multi-task reliably under a multi-tasking
environment.  It superceded the VCPI specification (see below).

DPMI is a specification that exists in two versions. The 0.9 version was
implemented in Windows 3.0. The 1.0 specification added new features while
remaining fully compatible with 0.9. OS/2 2.0 is compatible with the 0.9 level,
and adds some 1.0 features.

Virtual Control Program Interface (VCPI) is an earlier DOS extender
specification, created by Phar Lap and Quarterdeck.  While it allowed 386
expanded memory managers and DOS extenders to coexist, it did not address the
problem of DOS extenders coexisting within a multi-tasking environment.
Examples of applications written to this specification include Lotus 1-2-3
version 3.0 and Autocad/386 (Lotus 1-2-3 3.1+ changed the type of extender used
from VCPI to DPMI).


ΓòÉΓòÉΓòÉ 6.3.3. MVDM memory management ΓòÉΓòÉΓòÉ

MVDMs support all of the above types of memory, providing Virtual Device
Drivers for both EMS and XMS functions, thus allowing DOS applications all the
memory management functionality possible under DOS, including use of UMBs for
the DOS 5.0 LOADHIGH, DEVICEHIGH commands and for TSRs.  Indeed, DOS emulation
in OS/2 2.0 VDMs owns the UMBs, but can free them for application use with
statements in CONFIG.SYS or in DOS Settings.  Note that the availability and
size of UMBs depends on the same principle as under DOS (ie configuration of
that DOS virtual machine).  VDM DOS settings like MEM_INCLUDE_REGIONS and
MEM_EXCLUDE_REGIONS allow some detailed configurable control over UMBs for
separate VDMs.  This is an advantage over DOS itself, which for obvious reasons
can only apply one UMB configuration for all DOS applications that load,
leading to many DOS users maintaining multiple CONFIG.SYS files for their
different required configurations, and rebooting between them.

OS/2 2.0 provides Virtual Device Drivers (VDDs) for both EMS and XMS. The
Virtual Expended Memory driver (VEMM.SYS) supports up to 32 MB of expanded
memory per VDM, and the Virtual Extended Memory driver (VXMS.SYS) up to 16MB
per VDM.  These figures could be made higher, but are restricted for
compatibility with EMS and XMS support under DOS.  DPMI applications can access
up to 512MB in OS/2 2.0.  In contrast, DOS and DOS extenders like Windows 3.x
can offer extended memory only up to four times the physical memory in the
machine or 16MB, whichever is less.

Virtualising EMS, XMS access means one VDM's use of memory does not affect
others - more than one VDM can use XMS and EMS.

EMS and XMS memory is mapped into the system's linear address space, and
managed just like any other allocated memory. VEMM is compatible with LIM EMS
4.0 specification, and VXMS compatible with LIMA version 2.0 functions. The
amount of EMS or XMS is configurable in CONFIG.SYS or in DOS settings.


ΓòÉΓòÉΓòÉ 6.3.3.1. Protection ΓòÉΓòÉΓòÉ

VDMs operate in entirely separate process address spaces, and are controlled by
a VDM Manager.  They can thus be terminated on detection of illegal
instructions without affecting the rest of system, or when the application is
"hung".  Thus problems in one VDM do not corrupt others, nor the system.


ΓòÉΓòÉΓòÉ 6.3.3.2. Memory management ΓòÉΓòÉΓòÉ

Since VDMs take advantage of the virtual memory and paging facilities of the
386, they are swappable and, therefore, starting several DOS sessions will not
significantly increase system memory requirements. Note, also, that each DOS
session is individually configurable, so that EMS and XMS support can be
switched off if not required, reducing overall virtual memory requirements. As
always, of course, there is a balance to be made between memory usage and
performance when overcommitting memory.


ΓòÉΓòÉΓòÉ 6.3.3.3. DOS emulation ΓòÉΓòÉΓòÉ

All DOS services (eg I/O) are emulated within the MVDM kernel or passed to the
OS/2 kernel (eg file services). Most of this emulation runs in protected mode
outside the VDM (hence the large amount of DOS memory available). All
documented (and some undocumented) DOS features are supported (such as device
driver loading/support, program loading and execution, memory management) as
well as all documented (and some undocumented) DOS interrupts (INT 20h, INT
21h, INT 27h etc).  This provides a highly compatible "DOS 5.0-like"
environment.


ΓòÉΓòÉΓòÉ 6.3.3.4. Input/Output ΓòÉΓòÉΓòÉ

File Input/Output (I/O) in VDMs is made through the OS/2 file system, which,
via VDM DOS emulation, provides a compatible interface to file I/O for DOS
applications.  Thus DOS applications can, without modification, take advantage
of OS/2's Installable File Systems (IFS) like HPFS, and the enhanced FAT (see
File systems ). Other I/O is performed either by DOS emulation or via Virtual
Device Drivers (VDDs), such as BIOS, video, printer, keyboard (see below).  DOS
applications may continue to run and access system resources quite unaware that
those resources are virtual, and real access to devices is provided by OS/2 2.0
itself.  This guarantees compatibility but also allows DOS applications to take
advantage of the inherent strengths of the OS/2 environment.


ΓòÉΓòÉΓòÉ 6.3.4. Virtual Device Drivers (VDDs) ΓòÉΓòÉΓòÉ

OS/2 2.0 isolates DOS and Windows applications from I/O devices that are
controlled by OS/2 device drivers, by emulating, or virtualising them for one
or more DOS or Windows applications.  This is done by Virtual Device Drivers
(VDDs).  VDDs provide a virtual instance of the real hardware, which is
controlled by a physical protected mode driver (PDD - see PDDs below).


ΓòÉΓòÉΓòÉ 6.3.4.1. VDD features ΓòÉΓòÉΓòÉ

VDDs therefore provide the following support:

 1. Protection: VDDs allow DOS applications to access hardware and BIOS without
    affecting other VDMs or other protected mode processes. This prevents VDMs
    from corrupting each other, or the system.

 2. Virtualisation: VDDs avoid direct hardware access from DOS applications,
    but provide a virtual, or emulated, hardware state that lets the
    application think it is doing so.  To do this, they maintain a virtual
    hardware state for each VDM. This means applications can, for example,
    access BIOS and video RAM (as Lotus 1-2-3 does), and receive hardware and
    software interrupts.  In addition, VDDs can either perform I/O through a
    PDD, or directly address an I/O device itself for greater performance.  In
    this way, virtual video drivers can support fast screen I/O to match
    performance expectations of DOS users working with programs like 1-2-3.

 3. Sharing: VDDs allow sharing of devices across the system between DOS and
    OS/2 applications where there is a VDD/PDD combination for that device.
    There is also support for many DOS device drivers, to allow devices that do
    not have a VDD/PDD combination, to be supported in a VDM, for access
    exclusive to that VDM.

 4. Memory: the VDD is a protected mode driver which allows virtual device
    driver support to be loaded above the VDM's first megabyte of address
    space. This means that there is no memory impact on the use of VDDs for DOS
    applications. Only where DOS device drivers need to be loaded is there any
    impact under 1MB, and then the same as in DOS.


ΓòÉΓòÉΓòÉ 6.3.4.2. PDDs ΓòÉΓòÉΓòÉ

Physical Device Drivers (PDDs) correspond to OS/2 device drivers in 1.3, but
with an important difference: they execute entirely in protected mode, unlike
the bimodal 1.x device drivers.  Real mode interrupt handling is no longer
required since VDMs run in V8086 mode - all interrupt processing is therefore
done in protected mode.  Most OS/2 1.x device drivers work "as is":  the part
of the driver capable of being run in real mode (needed for the 1.x DOS
compatibility box) is not supported, but their protected mode portion will
usually work.  However, an old 1.x device driver is unlikely to service VDMs,
because the VDD requires support from the PDD that does not exist in older
drivers.

This also means that no portion of the OS/2 device drivers needs to be located
below the 1MB line, and therefore increases the size of the environment
available to DOS applications.  But DOS applications may still make use of
these PDDs through the VDD interface.


ΓòÉΓòÉΓòÉ 6.3.4.3. How VDDs work ΓòÉΓòÉΓòÉ

VDDs work by facing two ways: to the application, providing a virtual hardware
state, and to the PDD or device, performing the physical I/O.

At boot time, VDDs are loaded, and many establish communications with the
corresponding PDD via a direct call interface. The list in the section VDD
examples shows which VDDs have a direct interface with an OS/2 PDD. The VDD
controls the DOS application's access to the device, and relies on the PDD to
manage the physical hardware operations.

The example below, and the accompanying diagram, show how the virtual COM
driver (VCOM.SYS) works.

 1. The COM PDD services all hardware interrupts from the asynchronous ports,
    and buffers the data being transmitted or received.

 2. The direct call interface between the VDD and PDD allows the VCOM to
    emulate asynchronous BIOS functions to send and receive characters, or to
    set and query the state of a COM port, as well as receive the interrupts
    passed on by the PDD.

 3. All of the time, the DOS application believes it is controlling these
    functions itself (just like it would under DOS), and is having interrupts
    and data from the PDD and the COM port reflected back to it by the VDD to
    maintain the illusion. The DOS application is therefore accessing only a
    virtual copy of the COM port. The VDD gets control when a DOS application
    performs direct I/O to a port (IN our OUT instructions), or via BIOS or
    other software interrupts (INT instructions).

 4. OS/2 applications can simultaneously access the COM functions via the PDD
    using normal OS/2 function calls like DosOpen.


HowVDDswork

Not all VDDs need to operate with a PDD in this way. Some VDDs (eg video)
directly access the device for performance reasons. DOS applications still do
not address the device directly themselves - the VDD still virtualises the I/O
to the DOS application.

The VDD/PDD interface is required where hardware interrupts need to be
simulated into one or many VDMs (COM is a good example).  This is important so
that DOS applications that want to control the hardware device directly, do not
need to get control at interrupt time, but can be deferred until the OS/2
kernel dispatches the VDM task.  This preserves system integrity and maintains
overall system performance.  This interrupt latency, as it is called, may cause
problems for a minority of applications that are highly dependent on real-time
interrupts.  But the vast majority of DOS applications, even high speed
communications, can be dealt with successfully.

VDDs can be made swappable, and are installed using DEVICE= statements in
CONFIG.SYS.

Additional VDDs can be written by third parties for their devices, via a
published programming interface, using the Virtual Device Helper (VDH) services
provided by the MVDM kernel.

A VDD is required only if a device will be shared with other VDMs or OS/2
processes.  If a particular device is to be used exclusively by one DOS
application, the DOS device driver may be used.  Thus, OS/2 2.0 can provide
"generic" support to most DOS device drivers, but such support is limited to
that VDM. It does provide greater compatibility and a wider support of devices,
enhancing the DOS compatibility of OS/2 2.0 (see  DOS device drivers for more).
DOS Device drivers can be loaded via the DOS Settings (see DOS Settings ).


ΓòÉΓòÉΓòÉ 6.3.4.4. VDD examples ΓòÉΓòÉΓòÉ

VDDs exist for most of the common device types.  The following table lists some
of the ones that are included in OS/2 2.0:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 3. Virtual Device Drivers                                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé NAME      Γöé DESCRIPTION                       Γöé INTERFACES     Γöé
Γöé           Γöé                                   Γöé WITH PDD       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VBIOS    Γöé DOS system areas like ROM BIOS    Γöé                Γöé
Γöé           Γöé and interrupt vector tables are   Γöé                Γöé
Γöé           Γöé mapped from physical memory into  Γöé                Γöé
Γöé           Γöé the VDM address space by          Γöé                Γöé
Γöé           Γöé VBIOS.SYS.                        Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VCDROM    Γöé CD-ROM support                    Γöé      *         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VCMOS    Γöé CMOS data area and Real time      Γöé                Γöé
Γöé           Γöé clock support                     Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VCOM      Γöé Asynchronous COM ports            Γöé      *         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VDMA     Γöé Direct Memory Access (DMA)        Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VDPMI     Γöé DOS Protect Mode Interace - used  Γöé                Γöé
Γöé           Γöé in WIN-OS/2 and applcations like  Γöé                Γöé
Γöé           Γöé Lotus 1-2-3 3.1+                  Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VDPX      Γöé DOS Protect Mode Extender         Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VDSK     Γöé Disk/diskette, only for INT 13    Γöé      *         Γöé
Γöé           Γöé copy-protection                   Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VEMM      Γöé Expanded memory support - up to   Γöé                Γöé
Γöé           Γöé 32MB per VDD                      Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VFLPY    Γöé Floppy disk interface             Γöé      *         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VKBD     Γöé Keyboard - also has INT 9h emu-   Γöé      *         Γöé
Γöé           Γöé lation code to perform functions  Γöé                Γöé
Γöé           Γöé usually performed by CBIOS, such  Γöé                Γöé
Γöé           Γöé as key and scan code queuing,     Γöé                Γöé
Γöé           Γöé update of keyboard LEDs, and      Γöé                Γöé
Γöé           Γöé processing for Print Screen,      Γöé                Γöé
Γöé           Γöé SysReq, Break and Pause (INT 5h,  Γöé                Γöé
Γöé           Γöé INT 15h, INT 1Bh respectively).   Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VLPT     Γöé Printer                           Γöé      *         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VMOUSE    Γöé Mouse                             Γöé      *         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VNPX     Γöé Numeric co-processor (x87)        Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VPIC      Γöé Programmable Interrupt Controller Γöé                Γöé
Γöé           Γöé (8259)                            Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VTIMER   Γöé Timer                             Γöé      *         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VWIN      Γöé For WIN-OS/2 "seamless" support   Γöé      *         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VXMS      Γöé Extended Memory (XMS) specifica-  Γöé                Γöé
Γöé           Γöé tion - up to 16MB per VDD         Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Video     Γöé Supports all documented video     Γöé      *         Γöé
Γöé (VCGA,    Γöé modes from mono to XGA, including Γöé                Γöé
Γöé VMGCA,    Γöé the documented modes of VGA and   Γöé                Γöé
Γöé VEGA,     Γöé 8514/A.                           Γöé                Γöé
Γöé VVGA,     Γöé                                   Γöé                Γöé
Γöé V8514,    Γöé                                   Γöé                Γöé
Γöé VXGA,     Γöé                                   Γöé                Γöé
Γöé VSVGA)    Γöé                                   Γöé                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé  refers to base set of VDDs automatically loaded at system    Γöé
Γöé initialisation time; others can be loaded via DEVICE= state-   Γöé
Γöé ments in CONFIG.SYS.                                           Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 6.4. Multi-tasking ΓòÉΓòÉΓòÉ

OS/2 has always been highly regarded for its industrial-strength multi-tasking
design.  OS/2 2.0 continues those strengths, harnessing the CPU-level support
of the 386 processor for even more efficient multi-tasking.


ΓòÉΓòÉΓòÉ 6.4.1. Why do I need multi-tasking? ΓòÉΓòÉΓòÉ

Some people believe that they do not need multi-tasking, on the premise that "I
can only manage one thing at a time myself".  However, the simplest way of
understanding the need for multi-tasking is to imagine what happens when you
get an interruption at work.  Consider this simple scenario:

You are working on a report (using your word processor) when the telephone
rings.  It's the boss, and he wants the latest sales figures from you now.
Quickly, you stop what you're doing, put aside the word processor, and connect
to the database to run the report routine. While logging on and running the
report, you start your spreadsheet program, so you can put the report from the
database into the spreadsheet, to make some extra calculations that are
required.  When the report has run and the spreadsheet has recalculated, you
take the figures into your charting program to make a graph.  You may also wish
to cut and paste this graph into a new document that you create with your word
processor (which you call up quickly after you put it aside) to explain the
figures to the boss.  In addition, if you are a cautious person, you may back
up the report you have created and keep your own copy on diskette (in which
case it would have been nice to have started that formatting five minutes ago
when you were logging on!)  Once you've created the new document, with the
latest sales figures and calculations shown in a graph, you may wish to send it
to the boss via electronic mail.  Finally, you can return, after a brief rush
of activity, to your original report where you left it.

Such a scenario is characteristic of much of our work. Many of us are driven by
interruptions. In fact, it is not an exaggeration to say that any PC user who
has a phone can benefit from multi-tasking. The benefits are obvious:

o handle interruptions

o less waiting for one operation to complete (the "hourglass" in Windows 3.x is
  a sign of a platform with only limited multi-tasking)

o let the computer do the work while you stay productive

o handle "beneath the covers"  function like logging on, printing and running
  database reports

o give smooth, even performance between different tasks

But perhaps the most persuasive argument is to imagine how the above scenario
would have been achieved using DOS!


ΓòÉΓòÉΓòÉ 6.4.2. What is pre-emptive multi-tasking? ΓòÉΓòÉΓòÉ

Most users understand that multi-tasking allows more than one application to
run at once.  Of course, without multiple processors, they do not actually
execute instructions simultaneously - the CPU still only processes one
instruction at a time, but the operating system can divide CPU time between
several processes to make it appear to the user that those processes are
executing simultaneously.  Therefore most multi-tasking operates on the basis
of some form of CPU time-slicing.

Furthermore, it is important to distinguish between multi-tasking, where
applications continue to execute when in the background, and context switching,
where they lie dormant until given the user focus.  Some environments (such as
OS/2 1.3 DOS Box, Windows 3.x standard mode, and DOS 5.0's Task Switcher) are
only context switching.  In these cases, the background task does not receive
CPU cycles, and time is devoted only to foreground tasks.

Some of the tasks in the scenario outlined above can be achieved using systems
that offer only context-switching, or non-pre-emptive multi-tasking.  But a
pre-emptive multi-tasking system would allow the whole job to be achieved
faster and more efficiently, because the overall performance of the system
would be more balanced (see Why is it important? ).  Systems management tasks
like background "agents"  to collect configuration and performance data, are
very difficult to implement except in a pre-emptive multi-tasking system (see
OS/2 for client-server ).

Multi-tasking is pre-emptive when the processor allocates a finite time to each
task, and then switches the processor to another task, even if the first task
is not "ready" to give up the processor.  Non-pre-emptive implies that tasks
can "hold on" to the processor within certain limits.


ΓòÉΓòÉΓòÉ 6.4.3. Why is it important? ΓòÉΓòÉΓòÉ

To understand the significance of the difference between pre-emptive and
non-pre-emptive multi-tasking, it is useful to contrast the approach taken by a
DOS multi-tasker like Windows 3.x, with OS/2's approach.


Multi-tasking under Windows 3.x

Windows 3.x implements a time-slicing scheduler on top of DOS, which is in
itself a single-tasking operating system. In Windows Enhanced mode (which
requires a 386 or above - see Windows 3.x modes ), DOS applications run in
virtual machines which are pre-emptively multi-tasked; Windows applications run
together in one separate virtual machine; this process is pre-emptively
multi-tasked in relation to the other DOS sessions.

However, Windows applications themselves only support co-operative
multi-tasking, which means that Windows applications need to be "well behaved"
to give up the processor attention to allow other tasks to proceed, with
specific use of functions such as yield(). Windows applications are therefore
pre-emptively multi-tasked with respect to the rest of the system, but only
co-operatively among Windows applications. When a Windows program needs to do
some lengthy processing, or is waiting for I/O, it needs to take special
precautions against halting all other Windows programs for this duration.
Needless to say, some do not, and that is why the user can be frequently faced
with the hourglass icon for periods of time when doing extensive processing or
I/O. Furthermore, a Windows application has no guarantee of processor time
within any period, which can potentially cause problems for applications
needing regular processor attention, such as communications programs.

Even though DOS applications are pre-emptively multi-tasked in Windows, the
scheduler algorithm is fairly unsophisticated, time-slicing on a static
allocation basis (the proportions can be tuned by the user, but they remain
static). This means that, even though an application may be unable to make any
effective use of its processor share (for example when it is tied up with an
I/O request), it will get it anyway, even though more deserving candidates are
waiting their turn. Thus the multi-tasking can be bogged down with applications
that are "I/O bound", like Application 1 in the above diagram, waiting for an
I/O device to respond.

Finally, since DOS itself is single-tasking, it has only one I/O queue, and
cannot therefore easily handle multiple I/O requests except by processing them
serially. So extenders like Windows that rely on DOS may be further weighed
down by the single-tasking character of the operating system.

One of the best illustrations of the I/O limitations of Windows 3.0 or 3.1 is
to try running a spreadsheet recalculation, and a download from a host machine
to the hard disk, while also attempting to format a floppy disk from the DOS
prompt (not unlike the scenario we discussed previously). You will see that at
least one of the tasks (usually the diskette format if it is not in the
foreground) will process in a very "jumpy" way, and often will pause for very
long periods. It is not unusual in such a scenario, to see one of the tasks
come to a near standstill as the others progress. If one of the background
applications is a communications program, the lack of processing time available
to the background application may even result in loss of data.


Multi-tasking under OS/2

In contrast, OS/2 pre-emptively multi-tasks all processes, and also provides
another, more granular unit of execution - the thread.  Threads can be thought
of as distinct subroutines within a process, which can execute without
immediate reference to the main logic, such as file I/O, database read/write,
recalculation.  In OS/2 these threads can be dispatched separately, and be
multi-tasked with each other, and along with other processes.  In fact, the
basic unit of execution for the scheduler is the thread, and all processes
contain at least one thread.

The advantage of threads is that more time-consuming operations can be put into
separate threads, and the main thread of the program devoted to user input;
this helps the application to maintain an interactive and responsive feel even
when processing other sub-tasks in the background (see Application 1 in the
diagram).  In this way, threads help prevent the kind of "I/O bound" feel to
many DOS and Windows programs.  But it should be noted that use of threads
applies to more than just I/O operations:  it is a powerful tool that can be
used for any operation that can be run in background while allowing the user to
regain control of the application, for further input.

Threads do not exist in any currently available version of Windows (at the time
of writing). Indeed, though the promised future product, Windows/NT (a
different operating system) is claimed to offer multi-threading, Windows
applications will need to be rewritten to take advantage of this facility,
since Windows 3.x programs are inherently single-threaded. Porting from a
Windows 16-bit program to a future 32-bit version of the Windows API will not
be enough, nor can threads be easily added later; they must be woven into the
basic design of the program to be used effectively. In fact, another promised
feature of Windows/NT, symmetric multiprocessing, may have little value until
multi-threaded Windows programs exist.  Symmetric multiprocessing is the
ability of a system to run multiple threads of execution on different
processors concurrently (eg on multiple 486s within the same machine).  By
definition it requires a multi-threaded system, and therefore, to take full
advantage of it, multi-threaded applications, and Windows today is only
single-threaded. So this feature will need new versions of applications to show
its advantage. In fact, the most likely early candidates for multi-threaded
Windows/NT programs are those (like Sybase SQL Server and Oracle) that are
already multi-threaded by design because they exist today as multi-threaded
OS/2 programs. It is one of many examples where Windows/NT promises little that
is not already available with OS/2 Version 2.0.

Again, in contrast with DOS and Windows 3.x, the OS/2 scheduler is much more
intelligent than a simple time-slicer.  It can detect when applications are I/O
bound (like Application 2 in the diagram), and shift CPU time to another thread
or process.  Thus, priorities can be changed dynamically to preserve overall
system responsiveness.

And, to complete the picture, since OS/2 itself has a multi-tasking,
multi-threaded design, it can provide multiple I/O queues and therefore
overlapped I/O between processes. This helps to improve the perceived
performance, especially in heavy system loads.

The following table summarises the differences between Windows 3.x and OS/2
2.0:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 4. Multi-tasking - Windows 3.x and OS/2 2.0              Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                     Γöé WINDOWS 3.X         Γöé OS/2 2.0           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multi-tasking DOS   Γöé pre-emptive         Γöé pre-emptive        Γöé
Γöé applications        Γöé                     Γöé                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multi-tasking       Γöé co-operative        Γöé pre-emptive (if in Γöé
Γöé Windows applica-    Γöé                     Γöé separate VDMs)     Γöé
Γöé tions               Γöé                     Γöé                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Priority            Γöé static              Γöé dynamic            Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé I/O processing      Γöé serial, single      Γöé overlapped, mul-   Γöé
Γöé                     Γöé queue               Γöé tiple queues       Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

What this means to the user is that OS/2's multi-tasking is smoother, more
consistent, less likely to be bogged down by I/O or by an application
attempting to monopolise the processor, and more responsive and interactive in
feel.


ΓòÉΓòÉΓòÉ 6.4.4. Multi-tasking and the user interface ΓòÉΓòÉΓòÉ

One of the advantages of a graphical environment is that it can represent
concurrent tasks by icons and windows on the screen, thereby giving a visual
indication of the number and variety of tasks. This is true of both Windows and
OS/2.

However, OS/2 2.0 builds on the basic benefits of the "first generation" GUIs
like Windows 3.x and OS/2 1.3, and adds some features specifically designed to
aid smoother multi-tasking and switching between tasks:

o the "Window List" is more functional than the Windows 3.x task list, allowing
  several applications to be "resurfaced" on the screen, or closed, at once,
  rather than moving to and clicking on discrete icons for each task

o the ability to "hide" windows when not in use, rather than reducing to an
  icon on the screen , results in a less cluttered desktop, making it easier to
  find what you want quicker, especially in screen resolutions with limited
  screen "real estate", such as VGA.

o OS/2 2.0 allows whole groups of applications and data to be grouped together
  in a logical unit (a "project", as it were) by putting them together in a
  common folder. This is more convenient and flexible than just creating
  directories and copying files manually, as you would have to in DOS and
  Windows. (You can also be more flexible in naming such folders, going beyond
  the eight character limits even in a FAT file system - see  Descriptive names
  )

o Each folder can also be given a "workarea" property. This allows several
  applications to be opened, hidden or closed, together, simply by opening or
  closing the folder, rather than going to each window individually.  For
  example, a folder containing a spreadsheet, word processor and graphics
  applications may have all these programs running together, but then close
  them or hide them in a single operation on the folder, and restore them all
  to the state they were in previously, in another single operation. This means
  the whole state of work in progress can be quickly set aside, and another
  begun or resumed easily.  OS/2's ability to save and restore what you were
  doing from one boot to another is a specific example of this workarea feature

None of these user interface features appear in either Windows 3.x or in the
current beta test releases of Windows/NT.  The result of all of this is that
the Workplace Shell is much easier to use in a multi-tasking scenario than
older GUIs.  The user interface matches the internal design in being optimised
for multiple tasks, making it easy to move from one task to the next.


ΓòÉΓòÉΓòÉ 6.5. File systems ΓòÉΓòÉΓòÉ

OS/2 offers superior file system support, which leads to increased performance.
The OS/2 architecture also allows other file systems to be installed in a
modular fashion (Installable File Systems or IFS). It is therefore more
flexible in design to accommodate future enhancements; for example, OS/2 now
includes CD-ROM support via an IFS.

OS/2 also provides support for very large disks, a consideration that is
particularly relevant to server environments. OS/2 supports hard drives up to
2GB in size. In Windows 3.1 the limit is only 1GB.

OS/2 2.0 provides file I/O services not only to OS/2 applications, but to DOS
and Windows applications running in VDMs. Therefore, DOS and Windows
applications can take advantage of the advanced function, without having to be
modified, since the DOS emulation of MVDM provides a compatible interface to
the file system for DOS applications.

Both major OS/2 file systems have been improved under OS/2 2.0, allowing better
performance not only for applications themselves, but also in the paging
performed by the system when using virtual memory.


ΓòÉΓòÉΓòÉ 6.5.1. High Performance File System (HPFS) ΓòÉΓòÉΓòÉ

HPFS was first introduced to OS/2 in version 1.2, and is an example of the kind
of advanced function that has not yet been implemented in less sophisticated
systems like DOS.  It was introduced as an alternative to the File Allocation
Table (FAT) system which came from DOS.  HPFS is particularly good for managing
large disks and partitions or large files.  It provides fast and consistent
performance, outperforming DOS-based FAT systems in tests run by IBM, in nearly
all cases. (OS/2 2.0 implements an enhanced FAT system that uses some similar
caching features as HPFS, which can also give high performance in many
circumstances - see below).

HPFS is particularly good in disk utilisation (compared to FAT).  It uses a
highly contiguous file allocation system, which results in especially good
performance (relative to FAT) in accessing files or data in a cluttered or full
partition.  It implements a B-Tree directory structure and search algorithm, as
opposed to sequential under FAT.  HPFS also allows for multi-threaded I/O,
caching of directory pointers in memory for quicker access of last directories
used, and read-ahead and lazy write (lazy write buffers up write requests from
applications and commits them to disk after a given time or during disk
inactivity.)  These advanced features allow for substantial performance
increases and greater tuning.  HPFS can also provide write error recovery on
the fly with "hotfix"  facilities.

Since it is FAT-compatible at API level, applications running under OS/2 can
use either system, and do not have to be written specifically for one or the
other.  It also presents a consistent interface to other components of OS/2
like MVDM, to allow DOS and Windows to use HPFS volumes as if they were FAT.

HPFS also supports the use of long file names, for greater usability, so
instead of having LJS1290.TXT, you can have a file name "Letter to John Smith
December 90".  Obviously applications need to be coded with this in mind.  DOS
and Windows applications can use files that adhere to the 8.3 naming system on
HPFS without any difficulty.

HPFS has been enhanced in version 2.0 to add performance-related features such
as command chaining (providing a list of contiguous sector requests required to
fulfil an I/O request) and scatter/gather facilities such as are supported in
Small Computer Systems Interface (SCSI) adapters to gather physically
discontiguous pages in a data buffer, and perform I/O in a single operation.


ΓòÉΓòÉΓòÉ 6.5.2. Enhanced FAT ΓòÉΓòÉΓòÉ

OS/2 2.0 includes an enhanced version of the FAT file system which is
completely compatible with the FAT system under DOS.  This gives greater
performance but full compatibility with existing FAT systems.  It adds features
like lazy write and improved caching to FAT.  This means that DOS applications
running with a FAT file system under OS/2 2.0 will be substantially faster for
disk-based operations than under DOS.  All of these benefits can be obtained
without having to reformat your hard disk - the OS/2 enhanced FAT driver works
with existing DOS FAT volumes.


ΓòÉΓòÉΓòÉ 6.5.3. SCB exploitation ΓòÉΓòÉΓòÉ

OS/2 2.0 implements the Subsystem Control Block (SCB) architecture for more
intelligent and efficient disk access. SCB defines a standard way of
communicating between device drivers running on the main system CPU, and I/O
processors located on advanced function adapters (like SCSI) that are capable
of operating independently from the CPU. SCB therefore fits naturally with the
use of SCSI adapters, and will allow better exploitation of SCSI functions like
scatter/gather and command chaining.  The implementation is transparent to the
OS/2 user and the developer; there are no application considerations, simply
improved performance.  It is simply a means of getting more out of a system
that provides advanced intelligent adapters for disk I/O. Exploitation of
newer, more advanced devices such as SCSI is better under OS/2 than under
Windows, which does not provide such features.


ΓòÉΓòÉΓòÉ 6.6. Broad hardware support ΓòÉΓòÉΓòÉ

OS/2 1.x was separately distributed by both IBM and Microsoft. IBM delivered
IBM OS/2, which was specifically optimised for and supported on IBM equipment
(AT and PS/2 family), while Microsoft distributed MS OS/2 to its OEMs like
Compaq and Olivetti (many of these versions had manufacturer-specific
modifications too). This meant that there were different versions of OS/2
according to the machine it ran on. Although this was not in essence any
different than had always been the case for DOS, the perception was that
supporting OS/2 in a mixed hardware environment was hampered by the lack of a
"generic" version of OS/2.

This problem has been overcome in OS/2 2.0, which supports a broad range of
machines with an Intel 386SX or above, with a single version of OS/2. This
shows that OS/2 2.0 does not run only on IBM equipment.  Open hardware support
applies not only to the base system, but also to Extended Services for OS/2 and
OS/2 LAN Server (some models may require more memory installed to run the
systems extensions).  IBM supplies regularly updated lists of the models it has
tested via bulletin boards (see the list in OS/2 Bulletin Board Systems ) and
IBM representatives. Among the vendors whose models are supported, are Compaq,
AST, Olivetti, Toshiba, Hewlett Packard, Dell, Gateway, Wang, DEC, NCR, Tandy,
ACER, CompuAdd and many others. Ask your IBM representative to look for the
PCMTABLE package on the MKTTOOLS disk.

In fact, even though IBM cannot test OS/2 on all the models and manufacturers
in the market, it is likely that most PCs equipped with an Intel 386SX or above
processor, will work.  More models are being tested all the time, and IBM is
committed to working with as many manufacturers as possible to determine OS/2
compatibility.  Indeed, the evidence from user registrations for OS/2 2.0 in
Europe alone, suggests that users are already running OS/2 2.0 on hundreds of
machines that have not yet appeared on any "official" list.  By 2 September,
1992, 802 models had been recorded from registration cards that do not appear
on the list of tested models.

OS/2 is not limited to machines with Micro Channel architecture. Even the
supported PS/2 models include AT-bus machines like the Model 40, as well as
Micro Channel machines like the Model 57.  AT-bus, Micro channel and EISA
machines from a variety of vendors are supported.

Furthermore, IBM is now making OS/2 2.0 available, preloaded on the hard disk
of selected IBM PS/2 models, including the Models 56 and 57. This is a
convenience for users, who do not need to install the operating system at all,
but can switch on the PC to discover the system already set up for their use,
along with a number of new applets and help on using the system. IBM is making
this facility available to other IBM-compatible hardware manufacturers, and
arrangements have already been made with a number of vendors, including Dell
and Olivetti, to provide OS/2 2.0 with selected models in their hardware range.
Contact your supplier for the latest information.

OS/2 also has broad support for different displays, disks and printers.  Most
of the major display standards (VGA, 8514, XGA) have full support.  SuperVGA
(SVGA) support exists for some adapter types already (some existed in OS/2
1.3), and more drivers are appearing from the SVGA chip set vendors like
Trident and Tseng.  Many SVGA DOS and Windows drivers are also supported in
full screen DOS and WIN-OS/2 sessions, even if the main desktop has to run in
VGA mode if there is no PM screen driver.  IBM plans further enabling of
SuperVGA support in an update option to be made available by the end of 1992.

OS/2 supports 205 models of printer, which covers over 90% of the printer
market, from dot matrix, to inkjet and laser printers.  Models from the major
vendors like Epson, Hewlett Packard and IBM receive wide coverage (look at the
file PMSETUP.INF in the \OS2 directory for the complete list). There is also
generic text printing support which should work on any printer. Furthermore, if
a Windows driver exists for a device, it can be installed in WIN-OS/2, and used
for Windows applications running under OS/2 2.0 (the product includes
additional Windows printer drivers for Canon, HP and NEC printers).  Where both
a Windows and an OS/2 printer driver exist, they can both be installed in one
step at installation time.

Generic INT13 disk support is provided in OS/2 2.0, which should allow most of
the common drive types to work.  IBM and Adaptec have developed a common
specification which will make the development of vendor-specific SCSI drives
much easier.  Drivers already exist for some of the OEM SCSI adapter vendors.
More are in development, and IBM is producing tools to help support the
development of drivers for displays, printers and disks.

OS/2 1.x suffered from a relative lack of OS/2 device driver support, but OS/2
2.0 can make use of many devices via their DOS device driver (see DOS device
drivers ). Devices such as hand scanners and fax cards can often be supported
in this way, broadening the range of devices available to OS/2 users.

OS/2 device support is broadening as the industry increases its support, but
IBM continues to develop drivers itself and work with other vendors to ensure
that even wider support is provided.


ΓòÉΓòÉΓòÉ 7. Better DOS ΓòÉΓòÉΓòÉ

There are over 20,000 DOS applications available today. In order to be an
integrating platform for PC-based applications, the primary task for OS/2 2.0
is to fully support that wide range of applications.

OS/2 version 1.3 was limited in the support it could provide for DOS
applications, mainly due to the limitations of the 286 architecture on which
the OS/2 1.x base was designed. However, use of the 386, and in particular the
virtual 8086 mode of the processor, allows DOS applications support to be much
more extensive in version 2.0 - indeed, a better DOS than DOS itself.


ΓòÉΓòÉΓòÉ 7.1. Multiple DOS applications ΓòÉΓòÉΓòÉ

Several DOS applications can be run at once in OS/2 2.0.  All DOS applications
can be invoked from an icon on the Workplace Shell desktop, or from any DOS or
OS/2 command prompt.  They can be run in a full screen session (rather like
they were in 1.3), or windowed on the Workplace Shell desktop.  Both text-based
applications (such as Lotus 1-2-3 v2.2 and WordPerfect) and applications that
run in graphics mode (such as Lotus Freelance Plus or Harvard Graphics, as well
as the Microsoft Flight Simulator or other games programs) can be run.
Graphics mode applications can be run windowed alongside text-based
applications running in windows.  This cannot be done without restrictions in
Windows 3.0, and although Windows 3.1 does allow VGA graphics to run in a
window, this feature will not be available under Windows/NT, where, according
to Microsoft, the application will have to run full screen.


Multiple DOS applications in windows on the Workplace Shell desktop

DOS applications running in a window on the Workplace Shell desktop can take
advantage of many of the ease of use features of the Workplace Shell, such as
sizing the window to a convenient size, tiling windows so several applications
can appear alongside each other, and hiding them to make more space on the
screen while leaving the application running.  Furthermore, many DOS
applications will be able to take advantage of the font support in PM windows:
you can change the font size to better suit the size of the window you are
running in (the range of sizes available is determined by the display adapter
you are using - on VGA, for example, there are 10).  Again, all of this support
is provided by PM:  no modification is required to the DOS application.
Contrast this with DOS, where getting a small font size for applications like
Lotus 1-2-3, requires re-running the Install program, and the risk of creating
an invalid setup.

DOS applications that support the mouse get use of the mouse, even when running
in a window (there are DOS settings to give the DOS application exclusive use
of the mouse pointer while in the application window - see  DOS Settings ).
This is much easier to set up in OS/2 2.0 than it is under Windows 3.1 (Windows
3.0 did not support DOS windowed applications using a mouse), as it only
requires one change to the DOS settings (which are automatically set up for
many programs via the Migrate option - see Migrating applications ); in Windows
3.1, you need to have already installed the DOS mouse driver in AUTOEXEC.BAT or
CONFIG.SYS (thus reducing the memory available to all DOS applications whether
or not they use the mouse).

All of this means that, without changing any of your DOS applications, the
Workplace Shell environment can "add value" to the applications while
preserving full compatibility with the way they are used under DOS.


ΓòÉΓòÉΓòÉ 7.2. Application integration ΓòÉΓòÉΓòÉ

OS/2's DOS support is not simply a question of compatibility - under OS/2 2.0,
you can make your applications work together in a way that is not possible
under plain DOS.  It is possible to copy information from one application to
the clipboard, and paste it into another.  This can be between two DOS
applications, between a DOS application and an OS/2 application, or any
combination of DOS, Windows and OS/2 applications.

Moreover, both text and graphics can be cut and pasted between applications,
(although graphics can only be received by those applications that are capable
of handling bitmap data - mainly OS/2 and Windows applications). This allows
two-way sharing of data between applications.

This means that DOS applications not only integrate better with GUI
applications written for Windows and OS/2, but also with other DOS
applications, even though they may not have been written to work together.

Imagine, for example, if you were using the DOS versions of Lotus 1-2-3 and
WordPerfect, and you wanted to incorporate some figures from your spreadsheet
into the report you are writing on the word processor.  Under DOS, you would
need to quit one application (the word processor) to load another (the
spreadsheet), retrieve the spreadsheet file and make the conversion into a file
format the word processor understands (perhaps plain ASCII, thus losing any
formatting you have created in the spreadsheet), exit the spreadsheet
application, load the word processor and the report again, and import the data
into your report.  Whereas in OS/2 2.0, you can simply use the clipboard.  With
the applications running side by side in windows on the desktop, mark some data
from the spreadsheet, copy it to the clipboard, and paste it into the word
processor - all without closing files or applications. The clipboard takes care
of any data conversion.  As the number of applications you need to integrate
grows, so the difficulty of remembering different methods of data conversion
grows, but in OS/2 2.0, the user simply works with copy and paste each time.

Thus, standard, unmodified DOS applications can be integrated under the OS/2
Workplace Shell.  DOS applications can also be written to take advantage of the
OS/2 environment, or OS/2 applications written to start DOS applications.  One
example of this is the OS/2 command prompt in OS/2 2.0, which can start DOS
applications simply by typing the name of the .EXE file, just as one would from
a DOS command prompt.  This helps to reduce the need to differentiate between
DOS and OS/2 applications, from the user's point of view.

Another method of integration is via the named pipes mechanism, which allows
DOS and OS/2 applications to be written to communicate with each other.


ΓòÉΓòÉΓòÉ 7.3. Multi-tasking of DOS applications ΓòÉΓòÉΓòÉ

Not only can several DOS applications run at the same time, in separate windows
on the Workplace Shell desktop, but each continues to run in the background
while you are working on another.  In this way, DOS applications can take
advantage of OS/2's pre-emptive multi-tasking, overlapped I/O, and OS/2 file
system performance.  Let's take a look at each of these in turn:


ΓòÉΓòÉΓòÉ 7.3.1. Pre-emptive multi-tasking ΓòÉΓòÉΓòÉ

As was explained earlier ( Multi-tasking ), OS/2 was designed to manage
processor time smoothly between multiple applications, not only OS/2
applications, but also DOS and Windows applications running in Virtual DOS
Machines (VDMs).  This is more sophisticated than the simple time-slicing
mechanism employed by Windows 3.x, and takes into account, for example, when
applications are "I/O bound", waiting for an I/O device to respond.  In OS/2
priorities can be changed dynamically by the processor according to such
criteria, in contrast to the static approach employed by Windows 3.x.
Therefore, even though both environments employ pre-emptive multi-tasking for
DOS applications, the OS/2 scheduler is more sophisticated than Windows'
scheduler.  Relative performance between applications can be tuned by a number
of DOS settings (see  DOS Settings for some examples of DOS settings).

The result of all of this, is that OS/2 provides a more balanced performance
between applications, not only those from DOS, but between them and Windows and
OS/2 applications.


ΓòÉΓòÉΓòÉ 7.3.2. Overlapped I/O ΓòÉΓòÉΓòÉ

All DOS applications have their I/O requests serviced by OS/2 (although the
application makes calls to DOS I/O in the same way as usual, they are trapped
and serviced by OS/2).

This allows DOS applications to take advantage of OS/2's better I/O
capabilities without needing to be rewritten. Just by running under OS/2 they
can benefit from OS/2's ability to overlap I/O requests and services. This
improves performance in many scenarios, particularly where multiple
applications are running.


ΓòÉΓòÉΓòÉ 7.3.3. Access to OS/2 file system ΓòÉΓòÉΓòÉ

Although DOS applications have not been written to use the OS/2 file systems,
they can without modification use them and derive the same benefits as OS/2
applications do. All file access uses the OS/2 file system. Both the HPFS and
enhanced FAT file systems under OS/2 provide superior performance compared to
DOS  (**)

Therefore despite the inevitable multi-tasking overhead, many applications will
perform just as well, and some will perform better, than under native DOS.  In
test cases run by IBM, multi-tasking performance of DOS applications was
superior to that under Windows 3.x.


ΓòÉΓòÉΓòÉ 7.4. Memory usage ΓòÉΓòÉΓòÉ

Memory has been one of the biggest constraints on the development of the DOS
environment. The 640KB limit was for a long time an inhibiting factor for many
users and application developers. Despite many workarounds, such as the LIM
expanded memory, use of the HMA area, and the growth of DOS extenders (see
Memory: Conventional, Expanded, Extended for a more detailed discussion),
memory management under DOS is a complex and frustrating task, and there still
remain limitations for the large number of DOS applications written to use only
conventional memory below the 640KB mark.


ΓòÉΓòÉΓòÉ 7.4.1. Comparison with memory usage under DOS ΓòÉΓòÉΓòÉ

Part of the problem has been that successive releases of DOS have added
function, but removed some of the vital conventional address space. The
following chart shows the relative memory sizes free under various versions of
DOS:


DOS application memory space - a comparison

As the chart also shows, OS/2 Version 2.0 provides a DOS conventional memory of
633KB, at least as good, if not better, than even DOS 5.0 or DR-DOS 6.0. (The
respective vendors of both of the latter products promote the amount of memory
free as key selling points for their systems).

And that is only for default configurations. In the real world, many device
drivers are needed for various applications, whether for memory (expanded or
extended), connectivity (LAN, 3270), or mouse. In OS/2 2.0 these features are
supported without taking precious conventional memory away, whereas, even in
systems like DOS 5.0 that can move certain device drivers into the HMA area,
there is nearly always a conventional memory impact. The following table shows
some sample configurations which illustrate this point vividly:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 5. Memory comparison: OS/2 2.0, DOS 5.0, Windows 3.1     Γöé
Γöé          enhanced mode                                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé OS/2 2.0 Γöé DOS 5.0  Γöé WINDOWS Γöé
Γöé                                Γöé          Γöé          Γöé 3.1     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Conventional DOS memory after  Γöé 633KB    Γöé 622KB    Γöé 577KB   Γöé
Γöé default install                Γöé          Γöé          Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Various scenarios, built on default configuration:             Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé CONFIG #1 - POPULAR FEATURES                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé   file I/O                     Γöé YES      Γöé 1        Γöé 1       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé   EMS                          Γöé YES      Γöé 8        Γöé 8       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé   mouse                        Γöé YES      Γöé 14       Γöé 14      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé   fast file access             Γöé YES      Γöé 20       Γöé 20      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé REMAINING APPLICATION MEMORY   Γöé 633KB    Γöé 579KB    Γöé 534KB   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé CONFIG #2 - LAN CONNECTIVITY                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé   LAN adapter drivers and LAN  Γöé YES      Γöé 100      Γöé 100     Γöé
Γöé requester                      Γöé          Γöé          Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé REMAINING APPLICATION MEMORY   Γöé 633KB    Γöé 522KB    Γöé 477KB   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé CONFIG #3 - 3270 CONNECTIVITY                                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé   3270 adapter drivers and     Γöé YES      Γöé 28       Γöé 28      Γöé
Γöé emulator                       Γöé          Γöé          Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé REMAINING APPLICATION MEMORY   Γöé 633KB    Γöé 594KB    Γöé 549KB   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé CONFIG #4 - NLS PACKAGE/COUNTRY SUPPORT                        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé   NLS keyboard                 Γöé YES      Γöé 7        Γöé 7       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé   NLS display                  Γöé YES      Γöé 8        Γöé 8       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé   NLS printer                  Γöé YES      Γöé 11       Γöé 11      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé   NLS other (eg codepage)      Γöé YES      Γöé 5 (min)  Γöé 5 (min) Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé REMAINING APPLICATION MEMORY   Γöé 633KB    Γöé 591KB    Γöé 546KB   Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

Of course, the above configurations are by no means mutually exclusive:  it
will be very common to have elements from at least two of the configuration
groups above.  Indeed, groups 1, 2 and 3 together could be considered a fairly
essential configuration for a corporate, connected workstation, running any
modern DOS applications.  That means the difference between OS/2 and DOS grows
greater.  Note also, of course, that because Windows 3.1 and 3.0 are DOS
extenders, and run on top of DOS, that any reductions in the memory available
for DOS will be passed on to Windows, and to any DOS applications executing
under Windows.  While it may not be a problem for Windows applications running
in standard or enhanced mode, which use extended memory anyway, it will
substantially reduce the effectiveness of most DOS applications running under
Windows because of the constraints on conventional memory.

The reason OS/2 can provide all these features without loss of DOS application
space is because many features are supported by OS/2 device drivers, which are
available to OS/2 and DOS applications, and which do not affect the amount of
application space available to DOS applications. Only the DOS emulation kernel
resides below 1MB. In this way, the MVDM architecture makes available to DOS
applications the maximum amount of conventional memory.

In fact, if that were not enough, it is possible to increase DOS application
space still further.  One of the DOS settings is VIDEO_MODE_RESTRICTION (see
DOS Settings ).  This frees much of the video buffer space above the 640KB line
by restricting applications to text or CGA graphics mode only, allowing more
than 720KB memory free - an unheard of figure for DOS users!

This increased size of conventional memory space may even mean that, where DOS
users could not load TSR programs with larger DOS applications, they can under
OS/2! Furthermore, there are many scenarios encountered by Windows 3.x users
today, where they require access to a network, and a Windows application, at
the same time as using a DOS application that requires 590K or more memory (the
latter is not uncommon with the more modern DOS applications).  This
combination is usually not possible under Windows 3.x, and the user has to exit
Windows to run the DOS application, or remove network support.  Under OS/2 2.0,
this setup can be achieved easily.

And, of course, more conventional memory means more space for data and, for
some DOS applications, better performance, making OS/2 a better DOS environment
than DOS itself, by overcoming one of DOS's most fundamental limitations -
memory.


ΓòÉΓòÉΓòÉ 7.4.2. Expanded and Extended Memory ΓòÉΓòÉΓòÉ

OS/2 also supports the full range of other memory types supported under DOS and
Windows 3.x: HMA, XMS, expanded and extended memory and DPMI (see Memory:
Conventional, Expanded, Extended for an explanation of these memory types).
This means that not only do all DOS applications have more conventional memory
available, but those which have been written to access more memory can work in
the same way under OS/2 2.0.

For example, expanded memory conforms to the LIM 4.0 specification, and will
provide expanded memory to applications like Lotus 1-2-3 release 2 using the
standard DOS INT 67h services. Each VDM is provided with a separate EMS
emulation, so each can access as much expanded memory as necessary, and not
conflict with each other. The amount of expanded memory is configurable by the
user in DOS settings, as well as a limit set across all VDMs if required. In
Windows 3.x, expanded memory can only be used if a physical expanded memory
adapter is in the machine, therefore limiting the number of users who can mix
applications needing expanded and extended memory.

XMS support (LIMA version 2.0 level) is provided via a virtual device driver
(the same is true of EMS), and manages three types of memory: High Memory Area
(HMA), Upper Memory Blocks (UMBs) in the Upper Memory Area (UMA) and Extended
Memory Blocks (EMBs).  These are used by various DOS applications and TSRs, and
by Windows 3.x and DOS 5.0.  Just as DOS 5.0 can load part of the system into
the HMA, and device drivers into UMBs, so can OS/2 2.0 via the statements
DOS=HIGH and DEVICEHIGH= in CONFIG.SYS; these settings can also be made for an
individual VDM by changing the DOS Settings DOS_HIGH and DOS_UMB (see DOS
Settings ).  Furthermore, more extended memory can be provided to DOS
applications under OS/2.  DPMI-compliant applications such as Lotus 1-2-3
version 3.1+ can access up to 512MB of extended memory in an OS/2 VDM.

The key point is that OS/2 provides compatible services for extended and
expanded memory for DOS applications, as well as a larger conventional address
space, and also provides higher limits for many of the DOS applications that
use extended memory. And this can usually be provided as default without any
configuration effort on the user's part.


ΓòÉΓòÉΓòÉ 7.4.3. Multiple DOS applications - effect on memory ΓòÉΓòÉΓòÉ

Runing several DOS applications will not cause an excessive effect on memory
use or performance.  Because OS/2 operates a virtual memory system, you do not
need to have extra physical memory to have large memory applications, nor to
run several of them at once.  Any memory required above what is physically
installed will be found by using the disk as virtual memory.  VDMs are
swappable when inactive, reducing the overall overhead on physical memory.
Furthermore, applications that do not use EMS, XMS or DPMI, can have the
default VDM settings changed to remove any expanded/extended memory
requirements, thus reducing the overall virtual memory required.


ΓòÉΓòÉΓòÉ 7.5. Reliability and protection ΓòÉΓòÉΓòÉ

In DOS, most applications run in the real mode of the processor. DOS extender
applications execute mainly in protected mode, but still have to switch back to
real mode to perform certain I/O instructions (such as most calls to DOS
services) or when passing control to TSRs like device drivers. Protected mode,
as its name suggests, provides a measure of protection in the CPU between
processes, but while in real mode, applications can write to any area of
memory.  Errors can exist even in the best-written and well tested of DOS
applications, which can cause such system corruption under DOS, often leading
to a system crash or hang, forcing the machine to be rebooted.  Windows 3.x, as
a DOS extender, can be prone to some of these problems.  The problem can be
particularly acute under Windows, since one application that crashes may affect
all the programs running at that time.  Therefore, the potential for data loss
and for wasted time in resetting the system, is even greater.  That is why it
is crucial that a multi-tasking environment provides as much protection as is
possible.  There is a limit to how much can be achieved under DOS or a DOS
extender.

In fact, although Windows 3.1 is claimed to provide greater protection than
Windows 3.0, by "rebooting" individual DOS sessions and adding parameter
checking, it is still as prone as before to the risk of a DOS TSR (such as a
DOS network driver) taking the system out of protected mode into real mode (see
Reliability ). Neither Windows 3.0 nor 3.1 can prevent this "trap door" in its
system integrity as long as they run on DOS. It is, in architectural terms,
fundamentally prone to such problems, no matter what error checking code is
implemented at higher levels.

In OS/2 2.0, each VDM emulates an entirely independent instance of DOS, and
each VDM has its own separate address space (just like other processes under
OS/2), applications are protected from one another, and the system is protected
from applications. The VDM Manager (VDMM) within the OS/2 kernel can terminate
VDMs when an application or device driver performs an illegal operation, while
allowing other VDMs to continue running. While it is not impossible to crash
OS/2 (no system is secure from applications designed specifically to subvert
the normal means of protection), it provides a higher degree of crash
protection than any alternatives running on DOS.

Therefore, OS/2 is better protected than DOS, and provides all the benefits of
a DOS extender, including multi-tasking of DOS applications, without the
uncertainty of using an operating system (DOS) that was never designed for
multi-tasking.


ΓòÉΓòÉΓòÉ 7.6. Compatibility ΓòÉΓòÉΓòÉ

Of course, none of the benefits of extra memory, application protection,
integration, multi-tasking and so on, are of much value to users unless they
can be certain that their DOS application will run. It is impossible to
guarantee all applications will run, of course (there are more than 20,000
commercial applications without even counting the investment made by in-house
corporate developers - an impossible testing task!).  But it is worth
understanding how OS/2 2.0 has been designed to provide the maximum
compatibility possible in a multi-tasking environment.


ΓòÉΓòÉΓòÉ 7.6.1. Overcoming OS/2 1.3 limitations ΓòÉΓòÉΓòÉ

Since OS/2 2.0 is not constrained by some of the limitations of the OS/2 1.3
DOS box, particularly with regard to more memory (some DOS applications simply
did not have enough memory free to run in the OS/2 1.3 DOS Box), and support
for interrupt-dependent programs like communications, it is able to offer wider
compatibility for DOS applications.  However, OS/2 2.0 has taken compatibility
still further, and has been designed to take into account some of the aspects
of DOS applications which show their single-tasking heritage.

For example, some so-called "bad" applications directly address hardware
devices, and assume they have sole control over them. Many applications write
directly to the video memory buffer to improve screen refresh performance.
Perhaps the best known example of such an application is Lotus 1-2-3. In a
multi-tasking environment, it is important to be able to handle multiple
applications wanting to write to the screen at once, and maintain visual
consistency on the screen, while keeping maximum compatibility with existing
applications. OS/2 does this via its virtual device drivers. There is a virtual
video device driver, and also a virtual COM driver, which handles contentions
between applications wanting to use the COM port, and provides all DOS
applications with COM services at the same time.

The video virtual device driver is of further interest in that it provides
applications with fast screen I/O by allowing the foreground application to
write directly to the video hardware, but still insulating the physical
hardware from background VDM screen activity.  It also provides services for
DOS applications that use BIOS video routines, by intercepting the ROM BIOS
video interrupt (INT 10h) and performing the requested operations directly,
thus improving performance.


ΓòÉΓòÉΓòÉ 7.6.2. DOS device drivers ΓòÉΓòÉΓòÉ

Many common device types (video, keyboard, mouse, COM, EMS, printer) are
supported by virtual device drivers.  If neither a virtual device driver nor
OS/2 protected mode device driver is available, OS/2 2.0 can still provide
support for many DOS device drivers via a "generic"  DOS device support. This
would usually entail exclusive access to that adapter and device driver from
one single VDM.  This will be more than adequate for many DOS applications,
which use many device drivers for only one application anyway. And it has the
great advantage of allowing the large number of DOS device drivers, for the
plethora of adapters now available for PCs, to be used "as-is"  under OS/2 2.0.
Scarcity of protected mode device drivers was an inhibitor to adoption of OS/2
1.x; it need not be for 2.0.

IBM has demonstrated how DOS device drivers for scanners, FAX cards, MIDI
adapters can all be supported, and DOS applications that depend on them work
unmodified. Furthermore, there are a variety of devices in the banking and
manufacturing industries that can also be supported via this approach. Even
3270 applications can be supported with the DOS device driver in this  way.
However, a better approach would be to use an OS/2 device driver, as provided
with Extended Services for OS/2, for example, which can support both DOS and
OS/2 3270 applications simultaneously. This is better than running the DOS
driver in a VDM, which only allows access exclusive to that VDM. A similar
restriction exists in the March General Availability code, with DOS network
drivers (eg for Token Ring adapter).  These can often be used, but allow the
adapter only to be used within a single VDM (so that, for example, DOS 3270
communications via Token Ring cannot be used concurrently with DOS-based
networking through the same Token Ring adapter). This restriction can be
overcome for Token Ring using the Network Transport Services/2 product (NTS/2)
- see IBM Network Transport Services/2 running on an OS/2 2.0 base.  This
product provides a virtual device driver (VDD) for 802.2 access.  This VDD
allows 802.2 device sharing between VDMs so that, for example, Personal
Communications/3270 and program using the LAN can run together.

Even so, not all DOS device drivers are supported. Some block device drivers
(usually disk and tape drivers) are not supported, though some can run by
booting the "real" DOS inside a VDM (see Virtual Machine Boot (VMB) ).

The result of this is that OS/2 opens the door to an even wider range of DOS
applications and devices that can run as before, but taking advantage of the
OS/2 benefits described here.


ΓòÉΓòÉΓòÉ 7.6.3. What DOS version? ΓòÉΓòÉΓòÉ

OS/2's DOS emulation is just that - an OS/2-specific DOS kernel that emulates
DOS services. It is "DOS 5.0 - like", in that it should run all applications
supported by DOS 5.0.

Should applications require dependencies on a specific version of DOS there are
a number of strategies available to the OS/2 2.0 user.  First of all, it is
possible to "fake out" the DOS version, in other words, fool the application
into thinking you are using a specific version of a DOS component. This is
using the DOS_VERSION setting in DOS Settings (see below).  If this is not
enough, it is possible to boot the real version of DOS inside that VDM only
(see Virtual Machine Boot (VMB) ).


ΓòÉΓòÉΓòÉ 7.6.4. DOS Settings ΓòÉΓòÉΓòÉ

The DOS_VERSION option described above is just one of a number of "DOS
Settings" that can be changed to control the environment in each VDM. These are
set for that VDM only. Some settings can be made for all VDMs via AUTOEXEC.BAT
and CONFIG.SYS, such as DEVICE=...  statements (ANSI, VXMS, VEMM, VMOUSE, VVGA,
VCOM), and some (though not all) can be changed while the application is
running.  Several of these settings can also have an effect on DOS
compatibility, others can improve performance.


DOS Settings notebook

This means that each individual VDM can have its own optimised settings: some
with EMS, others without; some have DOS loaded high, others have special DOS
device drivers loaded in that VDM only. This gives great flexibility in
configuration, and allows the user to run different DOS applications
concurrently without having to maintain different CONFIG.SYS files and reboot
between them.

Among the commonly used or interesting settings are:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 6. Some VDM DOS Settings                                                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SETTING                Γöé DESCRIPTION                               Γöé DEFAULT   Γöé
Γöé                        Γöé                                           Γöé SETTING   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéDOS_BACKGROUND_EXECUTIONΓöé When set off, suspends execution of the   Γöé On        Γöé
Γöé                        Γöé program when it is in the background.     Γöé           Γöé
Γöé                        Γöé Useful for preventing degradation of      Γöé           Γöé
Γöé                        Γöé multi-tasking performance when a single   Γöé           Γöé
Γöé                        Γöé application is polling heavily for key-   Γöé           Γöé
Γöé                        Γöé board input.  Rather less fine control    Γöé           Γöé
Γöé                        Γöé than using IDLE_SENSITIVITY and           Γöé           Γöé
Γöé                        Γöé IDLE_SECONDS, which should be attempted   Γöé           Γöé
Γöé                        Γöé first (see below).                        Γöé           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DOS_DEVICE             Γöé Allows DOS device drivers to be loaded in Γöé Existing  Γöé
Γöé                        Γöé an individual VDM, rather than across all Γöé drivers   Γöé
Γöé                        Γöé DOS sessions. It adds to the drivers      Γöé from      Γöé
Γöé                        Γöé specified in CONFIG.SYS, which apply to   Γöé CONFIG    Γöé
Γöé                        Γöé all DOS sessions. The path and name of    Γöé SYS are   Γöé
Γöé                        Γöé the device driver are entered, and this   Γöé listed    Γöé
Γöé                        Γöé driver is available only for that VDM.    Γöé           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DOS_UMB                Γöé Gives the DOS emulation kernel use of     Γöé On        Γöé
Γöé                        Γöé Upper Memory Blocks, so that DOS TSRs and Γöé           Γöé
Γöé                        Γöé device drivers can be loaded into         Γöé           Γöé
Γöé                        Γöé addresses between 640 and 1024KB, thus    Γöé           Γöé
Γöé                        Γöé freeing memory for DOS applications below Γöé           Γöé
Γöé                        Γöé 640KB. This is similar to the DOS 5.0     Γöé           Γöé
Γöé                        Γöé function, allowing use of the DEVICEHIGH  Γöé           Γöé
Γöé                        Γöé and LOADHIGH commands. The UMB ownership  Γöé           Γöé
Γöé                        Γöé can be relinquished by turning this       Γöé           Γöé
Γöé                        Γöé feature off, if an application program    Γöé           Γöé
Γöé                        Γöé needs to manage UMBs. This setting can    Γöé           Γöé
Γöé                        Γöé also be made globally in CONFIG.SYS.      Γöé           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DOS_VERSION            Γöé Allows OS/2 to report a "fake" DOS        Γöé 20 (ie    Γöé
Γöé                        Γöé version number to a request from a        Γöé OS/2      Γöé
Γöé                        Γöé program in the VDM, in order to support   Γöé Version   Γöé
Γöé                        Γöé applications that check for a specific    Γöé 2.0)      Γöé
Γöé                        Γöé DOS version number. This is important for Γöé           Γöé
Γöé                        Γöé applications such as Lotus 1-2-3 version  Γöé           Γöé
Γöé                        Γöé 3.1Γö╝, which look for the presence of DOS  Γöé           Γöé
Γöé                        Γöé 3.3 or above.  The parameters set are the Γöé           Γöé
Γöé                        Γöé name of the DOS executable (eg            Γöé           Γöé
Γöé                        Γöé 123DOS.EXE) followed by the DOS major and Γöé           Γöé
Γöé                        Γöé minor version number (eg 3,30 for DOS     Γöé           Γöé
Γöé                        Γöé 3.3), then the number of times to "fool"  Γöé           Γöé
Γöé                        Γöé the application (255 means "every time")  Γöé           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DPMI_MEMORY_LIMIT      Γöé Specifies the maximum amount of protected Γöé 2         Γöé
Γöé                        Γöé mode memory available to DPMI applica-    Γöé           Γöé
Γöé                        Γöé tions running in a VDM (in MB). It is     Γöé           Γöé
Γöé                        Γöé important to set this figure high enough  Γöé           Γöé
Γöé                        Γöé for a WIN-OS/2 VDM running multiple       Γöé           Γöé
Γöé                        Γöé Windows applications in the same VDM.     Γöé           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé IDLE_SECONDS           Γöé Disables the IDLE_SENSITIVITY (see below) Γöé 0         Γöé
Γöé                        Γöé setting for a period of time after        Γöé           Γöé
Γöé                        Γöé "useful" work by the application has been Γöé           Γöé
Γöé                        Γöé detected.  Some programs appear to be     Γöé           Γöé
Γöé                        Γöé waiting for input, but then change and    Γöé           Γöé
Γöé                        Γöé continue other work.  The setting needs   Γöé           Γöé
Γöé                        Γöé to be made high enough to allow the       Γöé           Γöé
Γöé                        Γöé application to run fast enough, but not   Γöé           Γöé
Γöé                        Γöé too high as to give the program more      Γöé           Γöé
Γöé                        Γöé resources than it needs                   Γöé           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé IDLE_SENSITIVITY       Γöé Sets a threshold for judging when appli-  Γöé 75%       Γöé
Γöé                        Γöé cations will be deemed idle (ie waiting   Γöé (refers   Γöé
Γöé                        Γöé for I/O, polling etc). OS/2 2.0 can       Γöé to % of   Γöé
Γöé                        Γöé detect idle programs, especially those    Γöé maximum   Γöé
Γöé                        Γöé with a high rate of polling for input,    Γöé possible  Γöé
Γöé                        Γöé and gives them less time to run,          Γöé polling   Γöé
Γöé                        Γöé assigning the CPU to more "deserving"     Γöé rate)     Γöé
Γöé                        Γöé applications. This setting allows a user  Γöé           Γöé
Γöé                        Γöé to modify OS/2's "best guess" at what it  Γöé           Γöé
Γöé                        Γöé considers idle. The lower the number, the Γöé           Γöé
Γöé                        Γöé more likely OS/2 will judge the applica-  Γöé           Γöé
Γöé                        Γöé tion idle.                                Γöé           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé MOUSE_EXCLUSIVE_ACCESS Γöé Allows a VDM to run applications that     Γöé Off       Γöé
Γöé                        Γöé maintain their own mouse pointers, and    Γöé           Γöé
Γöé                        Γöé which manage their own mouse positions    Γöé           Γöé
Γöé                        Γöé and movements, by forcing the physical    Γöé           Γöé
Γöé                        Γöé mouse driver to send its movements        Γöé           Γöé
Γöé                        Γöé directly to the virtual mouse driver (and Γöé           Γöé
Γöé                        Γöé therefore to the DOS application) rather  Γöé           Γöé
Γöé                        Γöé than going through PM. Only one mouse     Γöé           Γöé
Γöé                        Γöé pointer appears when that VDM window has  Γöé           Γöé
Γöé                        Γöé the focus. Useful when running DOS appli- Γöé           Γöé
Γöé                        Γöé cations that require use of the mouse, in Γöé           Γöé
Γöé                        Γöé windows on the Workplace Shell desktop,   Γöé           Γöé
Γöé                        Γöé and prevents the situation where you can  Γöé           Γöé
Γöé                        Γöé see 2 mouse pointers, one for the DOS     Γöé           Γöé
Γöé                        Γöé application, and one for PM, and have     Γöé           Γöé
Γöé                        Γöé difficulty synchronising them. An example Γöé           Γöé
Γöé                        Γöé of a DOS application that can use a mouse Γöé           Γöé
Γöé                        Γöé in a VDM is WordPerfect 5.1 for DOS.      Γöé           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé PRINT_TIMEOUT          Γöé Sets the time in seconds after which the  Γöé 15        Γöé
Γöé                        Γöé spooler will close a print job initiated  Γöé           Γöé
Γöé                        Γöé by the VDM, and begin to print. This      Γöé           Γöé
Γöé                        Γöé means that printing can begin from DOS    Γöé           Γöé
Γöé                        Γöé applications that do not close their      Γöé           Γöé
Γöé                        Γöé print jobs, without having to exit the    Γöé           Γöé
Γöé                        Γöé DOS application                           Γöé           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VIDEO_FASTPASTE        Γöé Improves the speed of paste operations    Γöé Off       Γöé
Γöé                        Γöé from the clipboard to a DOS application.  Γöé           Γöé
Γöé                        Γöé Not all applications can support this.    Γöé           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé VIDEO_MODE_RESTRICTION Γöé Extends DOS address space beyond 640KB by Γöé None      Γöé
Γöé                        Γöé limiting video mode support to CGA, pro-  Γöé           Γöé
Γöé                        Γöé viding up to 96KB (depending on video     Γöé           Γöé
Γöé                        Γöé adapter installed) extra for DOS applica- Γöé           Γöé
Γöé                        Γöé tions                                     Γöé           Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

Help is provided with OS/2 2.0 to guide users in modifying these settings, but
it should be noted that much of the time, DOS settings will neither need to be
examined nor changed. The vast majority of applications will work with the
default settings.  Many of the most common DOS applications can have their
settings automatically created by the Migrate program (see below).


ΓòÉΓòÉΓòÉ 7.6.5. Migrating applications ΓòÉΓòÉΓòÉ

OS/2 2.0 provides a migration database (DATABASE.DAT) that contains parameters
and settings for commonly used DOS, Windows and OS/2 programs. This binary
database file is used by the Migrate Applications object to place the program
icons onto the desktop and customise their DOS or WIN-OS/2 settings to the
recommended values (which have been determined during pre-release testing).

This means that for many common DOS and Windows programs, there will be no need
to modify DOS settings, since the Migrate program will automatically place a
program object on the desktop with the optimal settings.  These are placed in a
"DOS Programs" folder and a "Windows programs" folder as appropriate.  Migrate
also allows applications not in the migration database to be migrated, but with
the default DOS settings, which can then be modified manually if preferred.
These programs are placed in folders called "Additional DOS programs" and
"Additional Windows programs" as appropriate.  All folders created by Migrate
are given the appearance of the group icons used in Windows 3.x and OS/2 1.3,
for visual familiarity. This aim is furthered by the fact that Migrate detects
the presence of the program icon for a Windows application, and adds it to the
program reference it creates in the OS/2 folder.  This means that Windows
applications appear in OS/2 with their normal icon.  DOS applications are given
the standard DOS icon for full screen or windowed sessions as appropriate. The
settings for each object can be modified to add a user-defined icon as
necessary. Many tools, such as CVTICO, exist on bulletin board systems, to
convert icons from Windows format to OS/2 format, so that any public-domain
icons that exist in Windows format for common DOS applications, may be used in
OS/2.

Migrate can be run during the install process or at any time after (the Migrate
object is found in the System Setup folder).


Migrate Applications object

System Administrators can set up their own custom migration database, to set up
applications unique to their environment, using the PARSEDB tool supplied with
OS/2 2.0. Thus, an optimal collection of DOS Settings can be determined for a
given program, and then supplied to other users.


ΓòÉΓòÉΓòÉ 7.6.6. Virtual Machine Boot (VMB) ΓòÉΓòÉΓòÉ

Should neither the basic DOS emulation of OS/2 2.0 nor any DOS settings provide
an answer to compatibility problems with a given DOS application, the ultimate
recourse is to boot the real version of DOS on which it depends, in a VDM. This
can be done either from the DOS boot diskette or from an image file created on
the hard disk. This applies not only to PC-DOS and MS-DOS versions, but also
non-IBM systems such as DR-DOS (and in theory any 8086 operating system
kernel).  A VMDISK utility is supplied with OS/2 to create disk images.

Once booted, the VDM is running that real copy of DOS, and the boot image path
or drive becomes the A: drive for that VDM.

The VMB feature, by booting the "real" DOS, provides the maximum achievable
compatibility in a multi-tasking environment.

Even so, there will be some architectural compatibility issues that even VMB
cannot address.  Most of these are limitations that arise from application or
device driver features that are fundamentally at odds with the principles of a
multi-tasking system.  These issues include VDM interrupt latency (which may
prevent some DOS "real-time" applications from giving sufficient performance),
support for VCPI DOS extender applications (see below), and I/O to
system-managed DASD that bypasses the file system (the latter is prohibited for
obvious reasons - this could pose a threat to the integrity of the whole file
system and affect other applications.)  But these are fairly minor restrictions
in an immensely wide scope of compatibility.


ΓòÉΓòÉΓòÉ 7.7. DOS extenders ΓòÉΓòÉΓòÉ

OS/2 2.0 can support DOS extender applications, those applications that have
broken the 640KB limit by running in protected mode and including their own
memory manager which "takes over" from DOS's. These include DOS multi-tasking
environments such as DESQview or Windows 3.x, as well as applications that
include DOS extender code, such as 1-2-3 3.1+.

OS/2 2.0 supports the DPMI (DOS Protected Mode Interface) specification for
extender applications, allowing applications written to this specification to
run under OS/2 2.0 and access up to 512MB of extended memory (see the
description of DPMI in Definitions ).  OS/2 2.0 is a DPMI host, which provides
DPMI services to DOS extender applications (DPMI clients).

VCPI applications will not run under OS/2 2.0 because they are architecturally
incompatible with a multi-tasking operating system (see Definitions ). VCPI
applications do not run under Windows 3.0 or 3.1 either.  However, many VCPI
applications have been rewritten to support DPMI, in order to support Windows
3, and OS/2 2.0 can take advantage of all of these.


ΓòÉΓòÉΓòÉ 8. Better Windows ΓòÉΓòÉΓòÉ

One of the most popular DOS extenders is Microsoft Windows. Windows 3.0 shipped
in May 1990, and gained a lot of media attention in the market. In April 1992,
Microsoft shipped an updated version, Windows 3.1, which was originally
described by Microsoft as a "maintenance" update, but has added a number of new
features, to address some of Windows 3.0's limitations. In this chapter, most
discussion will refer to both Windows 3.0 and 3.1 together as Windows 3.x,
since, except for some details, they compare to OS/2 2.0 in roughly the same
way.

Though Windows has undoubtedly had a significant impact on the market, there
has been considerable speculation in the press about how successful it has
been.  Microsoft claims that over ten million copies of Windows 3.0 were sold
up to March 1992 (although IDC estimate that more than half of these may have
been shipped with the purchase of a new machine, of which they and Creative
Strategies estimate only 30 and 55% respectively, are in use).  The company
also said that it shipped 3 million copies of Windows 3.1 in the first three
months after its shipment.  However, in a report in the Wall Street Journal  in
August, a spokesperson for the software retailer, Egghead, commented that the
preloading of systems like Windows with hardware, had affected retail sales.
She said that the company overstocked Windows 3.1 in anticipation of a heavy
retail demand for the system that failed to materialize.  "We bought strong
quantities of Windows 3.1 and they've been selling at a slower rate than we
anticipated," she said.

Windows Magazine, in its October 92 issue, estimated that the "real situation"
with regards to the number of Windows users was around 4.5 million. A recent
Dataquest study estimated that as of September 1992, 18% of the PCs in the US
are running Windows, which equates to around 2.6 million users.  This concurs
with figures quoted in OS/2 Magazine from ADAPSO/ITAA, saying that Windows has
penetrated only just over 10% of the total DOS market. Whatever figures are
used, Windows Magazine says that "financial analysts and software
companies...uniformly dismiss [Microsoft's figure of 13 million Windows users]
as meaningless."

There have also been a number of ISVs developing applications for Windows.
According to Microsoft, over 4,500 applications had been developed for the
Windows environment by March 1992.

Windows 3.x is, of course, in one sense an alternative or competitive solution,
since it provides a GUI and a basic multi-tasking environment.  On the other
hand, some customers require IBM to support the Windows applications that they
have purchased, under OS/2 2.0.  This section examines OS/2's relationship to
Windows 3.x, and how OS/2 can be a "better Windows".


ΓòÉΓòÉΓòÉ 8.1. What is MS-Windows? ΓòÉΓòÉΓòÉ

First of all, it is important to understand what Windows is. When it was first
released in 1985, it provided a GUI environment running under DOS, for which
applications had to be specially written to take full advantage. Although
versions before version 3.0 had gained some developer support, market success
was comparatively limited, and many of the major ISVs (eg Lotus, WordPerfect,
Borland) had not developed Windows-specific applications. Some of the reasons
for this were perhaps the lack of Windows-capable machines, the limited
multi-tasking, and the fact that it provided only limited relief for the two
main perceived limitations of DOS: the 640KB memory barrier, and multi-tasking
the DOS applications that people already had. Windows 3.0 overcame many of
these problems, especially in being able to multi-task DOS applications and
allowing Windows itself to take advantage of extended memory.


ΓòÉΓòÉΓòÉ 8.1.1. Windows 3.x modes ΓòÉΓòÉΓòÉ

The Windows environment itself has three modes, though the options available to
any user depend upon machine processor and installed memory.  These modes are
important to mention here as they are relevant to the discussion later of how
OS/2 runs Windows applications.  The italicised description of the three modes
comes from the MS-Windows User's Guide:


ΓòÉΓòÉΓòÉ 8.1.1.1. Real mode (NOT AVAILABLE IN WINDOWS 3.1) ΓòÉΓòÉΓòÉ

An operating mode that Windows runs in to provide maximum compatibility with
versions of Windows applications prior to 3.0.  Real mode is the only mode
available for computers with less than 1MB of extended memory.

Real Mode is equivalent to previous versions of Windows (2.x), and can address
640KB conventional memory, plus LIM 4.0 expanded memory (extended memory can be
used for a virtual disk or disk-caching only).  Real Mode requires an 8088
processor or above, and 640KB memory (384KB free conventional memory after DOS
and other memory resident software including network drivers).

Microsoft withdrew support for real mode in Windows 3.1, so that only standard
mode and 386 enhanced mode are now available. This means that programs
requiring Windows real mode (eg programs written for Windows 2.x) will not run
in Windows 3.1. However, Windows real mode programs (including Windows 2.x
applications) WILL  run under OS/2 2.0.  In this respect, OS/2 2.0 is providing
better support for Windows programs than Windows 3.1 itself.

Note that although Windows real mode runs in the real mode of the processor
(see Protected mode operation ), the two are not identical terms; even though
Windows 3.1 has eliminated Windows real mode, it cannot by its very design
prevent the system moving out of protected mode into the real mode of the
processor, and this represents a potential hole in system integrity (see
Reliability and protection and Reliability for more on this subject).


ΓòÉΓòÉΓòÉ 8.1.1.2. Standard mode ΓòÉΓòÉΓòÉ

The normal operating mode for running Windows.  This mode provides access to
extended memory and also lets you switch among non-Windows applications.

Standard Mode uses 286 protect-mode to give Windows and Windows applications
direct access to up to 16MB extended memory. Expanded memory for DOS
applications is only supported with physical expanded memory cards (not
emulation of expanded memory using extended memory). Standard Mode requires a
286 processor or above, 1MB memory (minimum 256KB of free extended memory), and
the XMS driver HIMEM.SYS loaded.  Windows applications need to be written to
comply with the memory management rules for Windows 3.x to run in Standard
Mode.

Standard mode is recommended by Microsoft when running only Windows
applications (ie no DOS applications) in certain configurations, even on a 386.


ΓòÉΓòÉΓòÉ 8.1.1.3. 386 Enhanced mode ΓòÉΓòÉΓòÉ

A mode that Windows runs in to access the virtual memory capabilities of the
Intel 80386 processor. This mode allows Windows to use more memory than is
physically available and to provide multi-tasking for non-Windows applications.

386 Enhanced Mode uses protected mode to give Windows and Windows applications
direct access to up to 16MB extended memory. The Virtual-8086 mode of the 386
is used to provide multiple DOS environments for non-Windows applications, and
virtual memory support is provided (for Windows applications only) using the
demand paging feature of the 386 processor. Most DOS applications can be run in
a window. 386 Enhanced Mode requires a 386 processor or above, 2MB memory
(minimum 1024KB of free extended memory), and the XMS driver HIMEM.SYS loaded.
Windows applications need to be written to comply with the memory management
rules for Windows 3.x to run in 386 Enhanced Mode.


ΓòÉΓòÉΓòÉ 8.1.2. Windows 3.x key aspects ΓòÉΓòÉΓòÉ

Windows 3.0 added a number of extra features to previous Windows releases, but
many people believe that its three main features are as follows:


ΓòÉΓòÉΓòÉ 8.1.2.1. DOS extender (memory > 640KB) ΓòÉΓòÉΓòÉ

Windows 3.x is first and foremost a DOS extender. It is itself a DPMI host
application running on top of DOS, which provides applications (in this case
Windows applications written specially for that environment) with extended
memory support to break the 640KB DOS limit.

Windows can provide additional memory for applications that have been written
to take advantage of this capability. But the vast majority of applications
still are written for the DOS environment, and even under Windows can only
address up to 640KB. In fact, as we saw in our discussion on memory available
under OS/2 2.0 and Windows earlier, since Windows inherits the DOS environment
for each DOS application it runs, it provides less memory in most scenarios
than would be available under OS/2 2.0, for the same DOS application in the
same configuration.

Nevertheless, since Windows, in standard and enhanced modes, runs much of the
time in protected mode (requiring a 286 or 386 processor for these modes), it
can itself take advantage of extended memory to run, leaving conventional
memory free for DOS applications (but at the cost of some overhead in
conventional memory for Windows itself - see Comparison with memory usage under
DOS ).


ΓòÉΓòÉΓòÉ 8.1.2.2. Multi-DOS environment ΓòÉΓòÉΓòÉ

Windows 3.x also offers, in its 386 enhanced mode, multi-tasking of DOS
applications.  Several DOS applications can be run at once, and most text-based
applications can appear in a window alongside other DOS or Windows
applications, in 386 enhanced mode.  However, Windows 3.0 enhanced mode does
not offer as flexible support as OS/2 2.0 does, for running graphics-based
applications - like Microsoft Flight Simulator - in windows on the screen
alongside text-based applications. DOS applications running in VGA mode can be
displayed in a window on the Windows 3.1 desktop, but according to Microsoft,
Windows/NT will not support windowed DOS VGA graphics at all.  (**)

In enhanced mode, Windows also provides a pre-emptive time-slicing mechanism to
multi-task between these DOS applications, though, as we saw before (
Multi-tasking of DOS applications ), OS/2 2.0's mechanism is more sophisticated
and will tend to provide a more balanced performance when multi-tasking DOS
applications.  For many users of 386 machines running on a DOS base, Windows
enhanced mode provides welcome additional function, and the ability to swap
between their DOS applications.  Standard mode allows multiple DOS applications
to be loaded, but they do not run in background nor can they be windowed.


ΓòÉΓòÉΓòÉ 8.1.2.3. Windows applications ΓòÉΓòÉΓòÉ

Of course, there have also been a number of applications written specifically
for Windows 3.x.  These are graphical applications written to the Windows APIs,
and can take advantage of extended memory (up to 16MB), the GUI environment, as
well as Windows system-supported functions like DDE (Dynamic Data Exchange).
Although the Windows environment was ignored by many of the major vendors at
first, there are now many applications developed specifically for Windows 3.x.
Applications developed for previous releases of Windows cannot run reliably
under the two higher modes of Windows, but only under real mode.  This means
that if you are running Windows 3.0 in standard or enhanced mode, and wish to
run, for example Excel 2.1, you must close all your Windows and DOS
applications, exit Windows and restart in real mode.  Windows 3.1, because it
does not support real mode, will not run Windows 2.x applications at all.  OS/2
2.0 can run real and standard mode Windows applications side by side on the
Workplace Shell desktop.

Although Microsoft claims that there are over 5,000 Windows applications in the
market, the majority of applications sales are still in DOS applications (to
say nothing of the installed base). There are many items of evidence to back up
this statement:

o Sales of DOS applications were still $112 million more than those of Windows
  applications in the second quarter of 1992 (Software Publishers' Association
  - SPA)

o In figures quoted in Windows Magazine, based on projections by Dataquest,
  Windows applications still represent less than 25% of the market in most
  application categories, and never as much as half in any (see the graph below
  which illustrates these figures in detail)

o Even in 1997, DOS applications will outsell Windows applications  (Dataquest)


    Windows application sales as a proportion of total PC application sales

o Many PC publications both in Europe and the US track sales of applications
  from a variety of channels, in order to determine a "Top 20" list of
  applications.  The trend since May 1990 is clear:  despite the apparent
  success of Windows in the market, few Windows applications make it into the
  Top 20, as the graph below shows.  In fact, there are rarely more than 5
  Windows applications in the top 20, and only two of them regularly appear -
  Excel for Windows and Word for Windows by Microsoft.


    Number of Windows applications in the top 20 selling applications

o There have also been several news items showing how the Windows applications
  market may not be as large as some vendors may have suggested. Here are some
  references from recent reports:

   - "The smaller software companies are not making money out of Windows, and
     Windows 3.1 is not going to change that" (International Data Corp.)  (**)

   - "The Windows market is really only the size of the Macintosh market"
     (Gordon Eubanks, CEO of Symantec, who produce Norton Desktop for Windows,
     one of the best selling Windows applications)

   - Lotus warned analysts of lower than expected revenues in June 1992,
     blaming "weakness in the market for Windows spreadsheets rather than loss
     of [market] share". "We're disappointed that the overall Windows apps
     market didn't explode like the channel thought it would" (Robert Weiler,
     Senior VP, Lotus)

   - Lotus is not the only major Windows vendor to suffer falls in share prices
     owing to lower sales of Windows applications:  Aldus reported lower
     earnings at the end of June 1992, owing to, among other reasons, "lower
     than expected sales of its Windows-based products".

   - Ruthann Quindlen, a software industry analyst, was quoted in an interview
     with Infoworld's editor, that she "regret[ted] saying... that Windows was
     going to create opportunities for small PC software companies". Listing
     many software companies suffering from slowing growth, earnings
     shortfalls, falling stock prices, she "had hoped that Windows would grow
     the market...But no." She concluded that "the only Windows apps doing well
     are Microsoft's"

   - "Companies that have invested a lot of money in developing Windows
     applications are battling for a small share of what is a very small pie"
     (Personal Computer Magazine (UK), May 1992)

o Windows applications are still heavily outnumbered by the 20,000 or more DOS
  applications, which also tend to have been longer in the market and built up
  a substantial installed base.

In fact, there is also much evidence to suggest that Windows itself is
outselling Windows applications by a factor of three or four to one:

o in the year to March 1992, when Microsoft claimed there were ten million
  copies of Windows shipped, IDC estimated 3.5 million Windows applications
  were sold.

o In early 1992, Microsoft stated that there had been $1.6 billion of Windows
  applications sold. If we take an average price of $500, this would give just
  over three million copies of all Windows applications together.

o In October 1991, Windows annual run rate, according to Microsoft, was 7.8
  million.  The SPA's estimate of the volume of Windows application sales for
  1991 was $1000 million.  This could mean that for every copy of Windows
  shipped, there was just over $120 spent on Windows applications, or about one
  quarter of a copy of Lotus 1-2-3 for Windows at its current recommended
  retail price!

If Windows were being used primarily to run Windows applications, one might
expect the user to have more than one Windows application. On this assumption,
the number of Windows application users may be only 15% or less of the total of
Windows users.  Either many people have bought Windows and are not using it, or
they are using it for something else.

A study of PC Magazine subscribers indicates a possible answer. The study was
conducted in the US by Ziff Davis Research Department and Alpert Research,
Inc., of 1840 PC Magazine readers.  The study has been reviewed by William
Zachmann, a well known independent commentator on the industry, in the June 11,
1991 issue of PC Magazine (Volume 10, Number 11, Page 97).  Zachmann reported
that respondents who personally used or were familiar with Windows, confirmed
that the most desirable features of Windows were its memory management,
multi-tasking and extended memory capabilities.  GUI capabilities, and the
availability of Windows applications were of only secondary importance.


Windows user survey quoted in PC Magazine June 11, 1991 issue

Zachmann's conclusion was:

     " "All of this strongly supports my contention that Windows 3.0's success
     is due more to its usefulness as a reasonably good DOS memory manager and
     multi-tasker, than to any groundswell of support for GUIs and Windows
     applications.  The study results also corroborate my observation that
     sales of Windows applications lag far behind reported sales of Windows
     itself." "

 Many observers agree with Zachmann, that it has been the combination of DOS
 extender and basic DOS multi-tasking, implemented on a DOS base, that has been
 the principal factor in Windows' success. This indicates that Windows is being
 used more as a DOS extender and multi-tasker than as an environment to run
 Windows applications. Even vendors such as Lotus, who are developing a suite
 of applications for Windows, have claimed that Windows is being used to run
 DOS applications more than it is used for Windows applications.

 This is an important consideration when we look at what it means to be a
 better Windows than Windows.  It seems as if many users look to Windows as a
 DOS environment first, and that Windows applications are currently a secondary
 issue.  Therefore, to be a better Windows than Windows, OS/2 2.0 needs to:

 o first, be a better DOS extender/multi-tasker
 o and run Windows applications, first ensuring compatibility and, if possible,
   some advantages over running it under Windows.

 As it happens, OS/2 2.0 is able to do both: create a better DOS environment
 for DOS applications, as well as provide full compatibility for Windows
 applications, and even some advantages in that respect.


ΓòÉΓòÉΓòÉ 8.2. OS/2 versus Windows as a multi-DOS environment ΓòÉΓòÉΓòÉ

It is clear that any discussion of Windows cannot ignore its DOS heritage. In
fact, this is both its great advantage, but also the source of most of its
shortcomings. Windows runs under DOS, which is an advantage from the point of
view of migration from DOS, but is also a disadvantage in the limitations that
DOS imposes on it.


ΓòÉΓòÉΓòÉ 8.2.1. Memory ΓòÉΓòÉΓòÉ

For example, we have already seen that since each DOS session created in
Windows inherits the whole DOS environment in place before Windows loaded, DOS
programs may have limited space in which to load. Although the combination of
DOS 5.0 and Windows 3.x helps to relieve some of the pressure on conventional
memory, most DOS applications have significantly less memory under Windows than
they do under OS/2 2.0 (see Comparison with memory usage under DOS for
details.)


ΓòÉΓòÉΓòÉ 8.2.2. Reliability ΓòÉΓòÉΓòÉ

DOS was designed as a single-tasking environment. Although DOS extenders like
Windows can provide multi-tasking under DOS, the base system was never designed
for it, and many of the applications running under such an environment assume
they are the only application in the system. DOS runs in real mode, and does
not provide protection between processes. Windows provides this protection
instead, allowing a measure of multi-tasking. However, Windows still needs to
use DOS for certain system functions, and so do many of the DOS-based TSRs (eg
Network and Communications drivers) that are needed to run alongside Windows,
and hence real mode is difficult to avoid when running Windows 3.x.  Any time
that is spent in real mode is a potential "trap door" for application errors to
violate the system's integrity.  Even though DOS applications run in separate
address spaces in enhanced mode, DOS and DOS TSRs still require access to real
mode, and the potential remains for an application conflict or bad pointer to
corrupt the DOS system area or Windows itself.

Furthermore, Windows applications all run in the same address space under
Windows 3.x, and therefore it is possible for an error in a Windows program, to
take down all the Windows applications together, and sometimes the whole
system, thereby affecting the DOS applications as well.  These symptoms occur
in a variety of ways, not always a "crash" or "hang" but sometimes messages
like "This application has violated system integrity" or "Unrecoverable
Application Error".

Windows 3.1 is claimed by Microsoft to provide greater protection from these
errors, by checking the parameters passed by applications, The users of Windows
3.1 will judge how effective this will prove, but it is a significant technical
challenge to provide full protection under DOS, unless an attempt is made to
eliminate real mode (of the processor, not Windows real mode) execution
altogether.  Indeed, although the message "Unrecoverable Application Error" no
longer appears, it has been replaced in many scenarios by "Application Error"
or "General Protection Fault".  In some circumstances, Microsoft still advise
that data in other sessions be saved, but then to exit and restart Windows,
perhaps even reboot.  In this case, the effects on a user would be little less
drastic than before.  In fact, though some have claimed that Windows 3.1
heralds "the demise of the UAE", the essential aspects of the Windows
architecture remain unchanged.  Windows applications still execute in the same
address space, still sharing a common Local Descriptor Table, or LDT (this is
why parameter checking is needed, but it only attempts to catch problems to
which the basic architecture leaves the system prone). Parameter checking is
much more important to Windows than it is for OS/2, which has other mechanisms
(notably separate address spaces) to protect the system from wayward
applications.

Furthermore, although many I/O and other functions are taken over by Windows (
leading Microsoft to call Windows 3.1 an "operating system"  (**) ), DOS and
DOS TSRs are still available (and indeed required if you want to run Windows on
a network, or with host communications), so the system still does not close the
real mode "trap door".

Any access to real mode is a potential danger; this is true even in OS/2 1.3,
where the DOS compatibility box ran in real mode and was therefore a potential
danger to system integrity.  The only certain way to high reliability is to run
the operating system only in protected mode.  No current version of DOS can do
this, but OS/2 2.0 runs entirely in protected mode: even when running DOS
applications, there is no real mode operation.

OS/2 has been designed for high reliability from the start, and version 1.3 is
already widely respected for its industrial strength design.  In OS/2 2.0, all
applications, both DOS and OS/2, and even Windows applications, run in separate
process address spaces, protected from each other, and much care has been taken
in the design to avoid giving wayward applications the potential to corrupt any
other applications or the system.  Usually in OS/2 2.0, the worst a "bad"
application can do is to cause an error that will cause the kernel to have that
process stopped and closed.  In these circumstances, the other applications
continue running unaffected.  This is why OS/2 has already been chosen by many
companies as the development environment for line of business, mission critical
applications.  If your business depends on your application, you do not want to
see it brought down with a UAE.

Some have tried to show that OS/2 can be "broken" by wayward applications, but
no operating system is safe from code written with inside knowledge of the
system internals, designed specifically to manipulate parts of the system in a
destructive way that mainstream applications would never attempt. The added
protection OS/2 offers compared to other DOS extender alternatives, is against
the occasional bugs in applications that cause them to write to memory where
they should not. The issue is not really whether either environment is totally
"crash-proof" but the overall integrity of the operating system in day-to-day
usage. In this case, we are not really comparing OS/2 to Windows, but OS/2 to
DOS.


ΓòÉΓòÉΓòÉ 8.2.3. Performance ΓòÉΓòÉΓòÉ

OS/2's multi-tasking design is more sophisticated than Windows, allowing DOS
applications to multi-task more smoothly. Windows has only a simple
time-slicing algorithm, which can be adjusted by the user to give "bias" to
certain applications. This means that priority levels are static, and do not
take into account, for example, when applications are I/O bound. On the other
hand, OS/2 can set priority levels dynamically, detecting when applications are
"idle" through polling or waiting for I/O, and assigning CPU cycles to other
applications. This advanced scheduler works in a similar way with OS/2
applications, pre-emptively multi-tasking them alongside the DOS applications.
Even Windows applications running in VDMs take advantage of this superior
scheduling mechanism for smoother multi-tasking. Windows 3.x offers only
co-operative multi-tasking between Windows applications, but pre-emptive with
respect to the rest of the system. This means that applications have to be
specifically written to give the processor up, with yield() calls, to allow
other Windows applications to have their fair share of the processor. (See
Multi-tasking of DOS applications and Multi-tasking for a more complete
discussion of this topic.) In OS/2 2.0, Windows applications can be
pre-emptively multi-tasked by running them in separate VDMs.

OS/2 offers a choice of two superior file systems, which DOS applications
running under OS/2 use whenever they do file I/O.  OS/2 2.0 has the High
Performance File System (HPFS) and an enhanced FAT file system, both of which
provide superior performance than under DOS in nearly all situations.  This
means that in file-based operations, OS/2 will nearly always be quicker than
DOS or Windows running the same combination of applications under the normal
DOS-based FAT system.  Furthermore, OS/2 is able to overlap I/O requests to the
system, taking advantage of its own multi-tasking design, allowing the system
to be more responsive to I/O request and keep applications waiting less.

The result of this is that the same combination of multiple DOS applications is
likely to run faster under OS/2 than under either DOS or any DOS extender like
Windows, if it does any significant disk-based I/O.  Applications that are more
compute-bound may show less difference (and in single tasking, DOS itself is
obviously likely to be faster in all except file-intensive operations).

And when more than one task is being done, OS/2's performance advantage becomes
evident.  Because of OS/2's superior multi-tasking, it can run background
tasks, such as file copying, communications, or spreadsheet recalculation, with
no visible impact on foreground work.  With Windows, the cursor movement can
lag behind the mouse movement, and displaying of characters can lag behind
keyboarding to the point where system becomes almost unusable until the
background job is done.

Here is an illustrative scenario from the testing of National Software Testing
Laboratories (NSTL), and independent testing and evaluation organisation: to
load MS Word for Windows on a PS/2 Model 57 with 8MB, with nothing else running
takes 7.2 seconds with Windows 3.1 and 9.3 seconds with OS/2 2.0.  If you do
the same load with an XCOPY in the background, Windows load time jumps to 41.1
seconds, compared with 15.3 seconds for OS/2.

Again, the comparison is really between OS/2 and DOS - Windows simply runs on
DOS and inherits its limitations.


ΓòÉΓòÉΓòÉ 8.2.4. Integration ΓòÉΓòÉΓòÉ

One of the other big differences between the DOS compatibility provided by OS/2
compared to that of Windows is in the area of how easy it is to set up DOS
applications to work. There are many ways in which DOS applications integrate
much more easily into the OS/2 environment than they do under Windows:

 o DOS Settings vs PIF files: Many have commented that Windows's method of
   assigning special settings to a DOS program via a Program Information File
   (PIF) is cumbersome. This is even more so compared to the consistency of the
   way the DOS Settings option is implemented in OS/2 2.0. Compare, for
   example, WordPerfect 5.1 for DOS. Both Windows 3.1 and OS/2 2.0 detect the
   program's presence on the disk, and create a unique set of program settings.
   But with OS/2 2.0, all of these settings are easily found together by
   clicking on the settings of the program object's icon. In Windows, clicking
   on the icon in Program Manager allows you to select its basic properties
   from the File Properties menu in Program Manager. But the dialog allows you
   only to change the command invoked, the working directory and icon. To
   change other options, you need to find the PIF file referenced in File
   Properties and edit the PIF file with the PIF editor (which by default is
   also in another program group). The PIF file contains all the other settings
   such as video mode, EMS/XMS settings, priority and idle detection, but also
   confusingly has options for startup directory and shortcut key, which are
   equivalent to (but overridden by) the settings in File Properties in Program
   Manager. So there are two places to look for settings, and sometimes two
   places to set the same setting. Furthermore, some important options are
   missing altogether from the PIF or Program Manager; mouse access in a
   windowed DOS application, for example, can only be achieved by first loading
   the DOS mouse driver (which is distinct from the Windows mouse driver - you
   need two mouse drivers if you want to use the mouse for both Windows and DOS
   applications) before starting the application.  Searching on "mouse"  in the
   Windows help system does not yield this information.  OS/2 allows the user
   to find all customisation for a given program in one settings notebook:
   command, working directory, icon, EMS, mouse access and so on.

 o Multiple working combinations: The amount of memory available when running a
   DOS program in Windows 3.1 enhanced mode is at most about 580K, and can be
   considerably less than 500K in a LAN-connected environment. And the more
   features that are required (eg 3270 access, country settings) means less
   memory for DOS sessions.  This can mean that larger DOS programs, including
   many newer DOS programs or latest versions, do not have enough memory to
   run.  Thus, users are faced with having to run different combinations of
   applications:  DOS program plus network but not with Windows; a Windows
   program with the network, but not the DOS application, and so on.  Some
   users even have to maintain different CONFIG.SYS and AUTOEXEC.BAT
   combinations, rebooting between them according to the combination of
   applications they are running.  Many users also have to buy third party
   utilities such as QEMM, and experiment with various settings, to get the
   amount of memory they need. Use of such utilities sometimes creates new
   integration issues, such as getting memory managers, disk cache programs and
   network drivers to co-exist.  In OS/2 2.0, not only can different
   applications be run at the same time as well as the network, but also any
   different combinations of settings can be easily maintained in DOS settings,
   and different configurations run at the same time.

 o Swap file: To allow for better performance in swapping to and from disk in a
   memory-constrained environment, Windows 3.x offers a permanent swap file.
   This is a contiguous area of disk, usually not accessible via DOS commands,
   and therefore preventing other files making any use of that space. Indeed,
   even if Windows does not need the full amount of space, it cannot be
   regained for application use until the feature is disabled. The OS/2
   SWAPPER.DAT file is designed to shrink as well as grow, so it is more
   flexible in allowing other files to be created alongside it.

 These are a just a few examples of the way in which OS/2's integration of DOS
 applications is superior to that of Windows 3.1, and such integration
 translates into lower running and support costs.

 In conclusion, we can certainly say that as a DOS environment, which appears
 to be the most important consideration even to many Windows users, OS/2 is a
 better Windows than Windows.  Now let's take a look at the other
 consideration, compatibility with Windows applications.


ΓòÉΓòÉΓòÉ 8.3. Running Windows applications under OS/2 ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 8.3.1. Standard mode support ΓòÉΓòÉΓòÉ

As far as OS/2 2.0 is concerned, Windows applications are just a special case
of DOS applications, which need a special environment (Windows 3.x) to run. The
key, therefore, to Windows applications compatibility, is to provide those
applications with as similar an environment as possible to what they have under
DOS, while taking advantage of the inherent design superiority of OS/2.

First of all, it should be understood that the Windows 3.0 shrinkwrapped,
retail package, can be run in a VDM in Windows real mode, (though Windows 3.1
cannot be run in this way because it does not support real mode) and Windows
applications started from within this VDM by the Windows Program Manager.  It
cannot be run in standard or enhanced mode because of the way Windows has
implemented the DPMI memory management scheme (it assumes it is a DPMI host and
cannot act as a DPMI client - see DOS extenders ).  Many Windows applications
run in real mode quite adequately.  In fact, applications written for Windows 2
cannot run in any other mode, and therefore will not run in Windows 3.1.  It
may be true that many Windows applications have been upgraded for Windows 3,
but this forces an upgrade on users who may be quite happy with the function in
their current package.  It means that the Windows upgrade path is now closed to
users of Windows 2 based applications.  OS/2 2.0 does not force such a choice,
and will run Windows 2 and Windows 3 applications side by side, without having
to exit and run in another mode.  In fact, some have commented that it is
ironic that OS/2 2.0 runs a wider range of Windows applications than Windows
3.1 itself.

Standard mode is needed for many Windows applications (eg Excel 3.0 and 4.0).
To accommodate these applications, OS/2 needs to provide additional support.
Basically, these applications need to access DPMI services for extended memory
support, which is usually supplied by Windows 3.x running in standard mode or
above. As we have seen already, OS/2 2.0 offers DPMI services and the ability
to access extended memory.

The other requirement is to supply Windows services to Windows applications.
This is done in OS/2 2.0 by modifying the Windows kernel and running it in
standard mode in a VDM. As part of the joint development and cross-licensing
agreement between IBM and Microsoft, IBM has access to both the Windows 3.0 and
3.1 source code.  IBM has modified the source to provide a Windows kernel
capable of running as a well-behaved DPMI client within an OS/2 VDM (the retail
version of Windows 3.0 can only be a DPMI host).  This means that OS/2 2.0
includes all the necessary Windows code to run Windows applications. A separate
copy of Windows 3.x is not required. The Windows environment in OS/2 is called
WIN-OS/2.

Since Windows 3.1 shipped after OS/2 2.0, OS/2 provides a modified Windows 3.0
kernel in the release made generally available in March 1992. IBM has the
ability to, and intends to, include Windows 3.1 support in a future update,
even though there are very few applications that require this support (see
Windows 3.1 ).

OS/2 therefore supports Windows applications running in standard mode in a VDM.
This means that the Windows kernel that runs under OS/2 runs in standard mode,
and Windows applications run just as they would under DOS Windows 3.x in
standard mode. The use of the VDM design, which provides a self-contained DOS
environment, means that the environment is identical, from the application's
point of view, to running under Windows loaded in standard mode, on DOS. This
design therefore provides the maximum compatibility with the DOS/Windows
environment. In fact, it offers a wider range of compatibility, since Windows 2
applications, which require real mode operation under Windows 3.0 in DOS, can
be run alongside Windows 3.0 applications running in standard mode.  This
combination is not possible at the same time in Windows 3.0, and is not
possible at all in Windows 3.1, since Windows real mode has been discontinued
in Windows 3.1.


ΓòÉΓòÉΓòÉ 8.3.2. 386 Enhanced mode ΓòÉΓòÉΓòÉ

Windows has another mode - 386 enhanced mode, which requires the 386 processor.
OS/2 2.0 does not need to support enhanced mode for Windows applications, since
for most Windows applications, there is no difference between standard and
enhanced as far as the application itself is concerned. Standard mode provides
Windows applications with all the memory management and other functions they
need. Enhanced mode adds to standard mode the capability for multi-tasking DOS
sessions and demand paging for efficient virtual memory, both of which are
provided (in a superior fashion) by OS/2 2.0 itself. Indeed, Microsoft
recommends in the Windows 3.0 manual on page 429, that users running only
Windows 3.0 applications should run in standard mode, even on 386 systems with
2-3MB of memory, as there is a performance improvement in doing so. Therefore,
OS/2 2.0 provides equivalent function to enhanced mode for most users.

There are, however, a small number of Windows applications which require
enhanced mode to run. These are not supported in the first release of OS/2 2.0.
It is believed that there are only at maximum three or four of these in the
market, which represents less than 0.1% of Windows 3.x applications, if we take
Microsoft's figure of 5,000 Windows applications. Such applications require
enhanced mode either because they rely on features only available in enhanced
mode, or have been coded using the WINMEM32.DLL, a set of routines that provide
some 32-bit functions for Windows applications, such as Wolfram Research's
Mathematica and Caere Omnipage Professional.  It is unlikely there will ever be
many in the latter category of applications, since the WINMEM32.DLL is very
difficult to use, and Microsoft themselves warn in Appendix E of the Windows
Programmers Reference: "only experienced Windows application programmers with
extensive experience writing assembly-level code should attempt to use these
functions in an application."  That is because even something as basic as
memory management using these routines can be very complex, requiring the
programmer to create his own assembly language interfaces between the 16 and
32-bit parts of his program (note that such "thunks" are provided by OS/2 2.0
between 16 and 32-bit modules - see Mixed 16-/32-bit environment ).  Charles
Petzold, possibly the most widely respected authority on Windows programming,
whose book on the subject is a standard reference work, concluded on this
subject that "something is seriously wrong when memory access becomes
difficult", and contrasted the current Windows approach with the ease of 32-bit
memory management under OS/2 2.0.  At the time of writing, Microsoft had not
stated whether WINMEM32.DLL applications would be able to run under a 32-bit
Windows environment and have said that it is unlikely that such Intel-specific
applications would run unchanged in a future version of Windows/NT running on a
RISC processor.

So, although there are a very small minority of Windows applications that will
not run under OS/2 2.0, the vast majority will run, and in a mode which allows
access to their full function.  Indeed, to the Windows application, the
environment will appear exactly the same as under DOS/Windows standard mode,
but there will be greater overall protection, and the ability to pre-emptively
multitask such applications along with DOS, OS/2 and other Windows
applications.


ΓòÉΓòÉΓòÉ 8.3.3. Contrast with previous approaches (BCL) ΓòÉΓòÉΓòÉ

It should be emphasised that IBM's approach of building Windows code into OS/2
is quite different from previous approaches by Microsoft, which have included a
Binary Compatibility Layer (BCL) which attempted to translate Windows calls to
PM calls in real time.  By providing the "real" Windows code, modified mostly
for memory management purposes, the potential for performance degradation is
greatly minimised.  Those who previously suggested that IBM's approach is
"impossible" may have been thinking of a BCL-type approach, rather than the
method actually used in OS/2 2.0.


ΓòÉΓòÉΓòÉ 8.3.4. How they run ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 8.3.4.1. Single session or separate session ΓòÉΓòÉΓòÉ

Windows applications can be started from an icon in the Workplace Shell, just
like other applications: OS/2 16 and 32-bit, DOS etc. They are launched into a
VDM which is, like other VDMs, protected from the rest of the system. Users
have a choice of loading the Windows application into its own VDM (even if
other Windows applications are already running in separate VDMs) or being
loaded into a VDM which contains other Windows applications. These are termed
Single application and Multiple application VDMs (SAVDM/MAVDM) respectively.
This is controlled in the settings for the program object: when choosing
"WIN-OS/2 window", you can check (SAVDM) or leave empty (MAVDM) the check box
entitled "Separate Session"; or if running in a WIN-OS/2 Full Screen session,
simply load the program from the Program Manager in the Full Screen session in
the normal way.


Single and Multiple application Windows groups

Single application Windows sessions load the application executable (eg
EXCEL.EXE for Excel 3.0) along with a modified WIN.COM file (WINOS2.COM). This
is exactly the same effect as typing "WIN EXCEL" when running DOS/Windows 3.x.
The Windows application then runs under the WIN-OS/2 environment, in its own
VDM.  As far as the application is concerned, this is exactly the same as
running under DOS/Windows; the modified Windows kernel provides the same
services in a compatible way.  Additional Windows applications can be loaded
into separate VDMs in the same way.

Multiple application Windows sessions allow the user to run several Windows
applications within the same VDM.  This is the closest possible fit to the
DOS/Windows usage, especially when run in a separate WIN-OS/2 Full Screen
session, when it is difficult to tell you are not running under DOS. In this
way, users migrating to OS/2 from Windows are able to run under OS/2 but have
the general "look and feel" of their DOS-based Windows environment.

Single application VDMs provide the best protected way to run Windows
applications under OS/2. Since the application runs in a self-contained Windows
environment in its own VDM, it is fully protected from other applications, and
the system is protected from it.  This means that if the application crashes
for any reason, it only affects that VDM, and in fact only that one
application.  Even other Windows applications running in other VDMs are not
affected.  This is a significant improvement in reliability over Windows under
DOS (both 3.0 and 3.1), in which, since all Windows applications and Windows
itself share the same Local Descriptor Table (LDT), a failure in one Windows
application may bring down the entire Windows system or corrupt the data areas
of other Windows programs.

But even though the SAVDM is fully protected, it can still share data via
clipboard or DDE with other Windows applications or PM applications (see
Clipboard/DDE ).

However, each SAVDM must load its own copy of WIN-OS/2, and will therefore
increase the overall working set of OS/2, affecting memory requirements and
performance.  If memory is limited, MAVDMs provide the ability to run several
Windows applications with less resources required.  But this is at the cost of
losing the additional protection of the separate VDM.  If one Windows
application crashes within a Multiple application Windows session, it may cause
all the applications within that VDM to fail; but the effect is only within
that VDM - the other VDMs running DOS or Windows applications within other VDMs
are not affected and continue executing.  So even here there are benefits
running Windows applications under OS/2, for greater reliability from system
crashes. MAVDM will also lose the additional WIN-OS/2 benefit of pre-emptive
multi-tasking for the Windows applications within that VDM (but not any other
WIN-OS/2 sessions).  MAVDM is also a requirement where Windows applications
need to communicate with each other via shared memory, and where applications
want to use OLE between each other (see OLE ).


ΓòÉΓòÉΓòÉ 8.3.5. Full Screen or Seamless ΓòÉΓòÉΓòÉ

In the Limited Availability version of OS/2 2.0 which shipped in December 1991,
a WIN-OS/2 VDM ran only in a separate Full Screen session.  The user clicked on
an icon (eg WordPerfect for Windows) in the Workplace Shell, and a separate
Full Screen WIN-OS/2 VDM was launched along with the Windows application.  The
user could toggle back and forth using Alt-Esc, Ctrl-Esc, or a little OS/2 icon
that appeared in the corner of the Windows screen.  But this was the only
visual clue that you were in OS/2 at all:  the screen looked exactly like
DOS/Windows 3.0.  This Full Screen function is still provided in the product
shipped in March 1992 (there is an icon marked "WIN-OS/2 Full Screen" in the
Command Prompts Folder).

There are some minor differences between the icons that appear in the WIN-OS/2
Full Screen environment versus DOS/Windows:  many of the Windows
mini-applications and utilities (eg Notepad, games, PIF editor) have OS/2
equivalents or are no longer relevant; others, such as the clock, are retained
for compatibility.  OS/2 adds icons for returning to PM from a WIN-OS/2 Full
Screen session (since the Windows user wants to have access to either Ctrl-Esc
or Alt-Esc key combinations for compatibility with his Windows environment) and
for DDE management (see later).

The Windows print manager is retained, and Windows printer device drivers
supported. The Windows Control Panel can be used to install Windows printer
drivers not supported by OS/2, and to configure other Windows printer drivers,
just as in DOS/Windows.

This full screen Windows function fulfilled the commitment made in April to
provide Windows compatibility in 1991 (completed in the Limited Availability
(LA) product shipped in December 1991).  But during the early autumn of 1991,
IBM received feedback from many of its beta testers to bring forward the
functions it had been discussing for a future version to run Windows
applications on the same screen as other DOS and OS/2 applications.  The
decision was taken to move the GA (General Availability) date to March 1992 to
allow this function (and others) to be added.  It was first shown in Lee
Reiswig's "OS/2 live"  show at Fall Comdex in October 1991.

This latter function has since been called "Seamless Windows". But the term is
not very accurate; it was chosen by the marketplace, not by IBM. It is
important, in fact, to note that most of what makes OS/2 2.0 "a better Windows"
was already delivered with the LA product in December:  protection between
applications, pre-emptive rather than co-operative multi-tasking for better and
more consistent multi-tasking performance, integration with other DOS and OS/2
PM applications via clipboard and DDE, with no loss of compatibility.  Many
people still run their Windows applications full screen, even with the GA
version, as it does what they need.  In fact, full screen has some benefits
over Seamless operation (better performance, especially for clipboard and DDE,
and more visually compatible with DOS/Windows).

In any case, much of the WIN-OS/2 environment represents a "seamless" migration
from the DOS/Windows environment anyway:  automatic installation of Windows
printer drivers, re-creation of existing Windows program groups and WIN.INI
settings.

Also, for most users, the most important aspects of integration are to be able
to run all applications from the same user interface, and to allow all
applications to share data.  These benefits apply to Full Screen and Seamless
operation alike. Windows applications can be loaded from the same folders as
DOS and OS/2 applications, from the new Workplace Shell, and data can be shared
via clipboard and DDE.

But in the context in which it refers to the opposite of "Full Screen",
"Seamless" operation merely refers to the way the WIN-OS/2 application is
displayed on the screen, in its own window on the Workplace Shell desktop as
opposed to in a separate Full Screen session (see the diagram below, using
Excel 3.0 for Windows):


Windows Full Screen and Seamless Sessions

Note that the fundamental way the WIN-OS/2 application works is the same
whether it runs Full Screen or Seamless:  it runs in its own protected VDM; it
runs with the modified Windows code, it runs in standard mode.  But the
additional element is the way the screen output is mapped on to the Workplace
Shell screen.  Also, you can have any combination of SAVDM/MAVDM, or Full
screen/Seamless:

 o SAVDM Full Screen (WIN-OS/2 Full Screen in DOS Settings)
 o SAVDM Seamless (WIN-OS/2 window in DOS Settings - "Separate Session"
   checked)
 o MAVDM Full Screen (WIN-OS/2 Full Screen object in "Command Prompts")
 o MAVDM Seamless (WIN-OS/2 Window - "Separate Session" unchecked; the default
   for most applications)


ΓòÉΓòÉΓòÉ 8.3.5.1. How does it work? ΓòÉΓòÉΓòÉ

Please note that what follows is a simplified explanation. There are no
specific considerations for users or programmers in the way the Seamless
WIN-OS/2 operation works.

The two key considerations in the design of the "Seamless" function were:

  1. Maintain compatibility
  2. Retain high performance

 This resulted in a more "low level" implementation to avoid the limitations
 inherent in attempting to map Windows calls to PM.  Instead, both the PM and
 Windows screen device communicate with each other via a Virtual Device Driver
 (VDD), VWIN, providing synchronisation of access to the video display
 hardware.  Each device driver "owns" its section of the screen. (This was a
 significant task in the time available, even for VGA; it can easily be
 understood why Seamless function is only available for VGA in the GA March 92
 release, but drivers for above VGA are in development and will be delivered
 later in 1992).  A new entry in WIN.INI, SDISPLAY.DRV= , denotes the change.
 The best way to understand the way it all works is to consider an example.
 Refer to the numbered diagram below while reading the following explanation:


  How Seamless Windows works

 When a WIN-OS/2 application creates a window, the Windows screen device driver
 requests the PM screen device driver to open up a "black hole" of the same
 dimensions (see step 1 in the diagram).  The Windows device driver then has
 control of the video hardware and paints into this space (step 2).The result
 is that the WIN-OS/2 application (which is completely unaware of this process)
 creates its main and secondary windows on the Workplace Shell screen alongside
 (and sometimes overlapping) other OS/2 application windows. Notice this means
 that the WIN-OS/2 application paints its own frame controls and mouse pointer
 (eg title bar, minimise/maximise buttons) and even the infamous Windows
 hourglass!), and these controls will therefore look like Windows controls, not
 PM ones.  If you put Excel for Windows and Excel for OS/2 side by side, you'll
 see the difference.  Although this creates some minor visual inconsistencies
 (most users don't even notice!), it preserves compatibility and performance.

 The WIN-OS/2 application window can be sized and moved as normal merely
 changing the co-ordinates of the "black hole"  into which it paints (see steps
 3A and 3B).  The PM screen device driver repaints any part of the PM screen
 space previously governed by the WIN-OS/2 window.  Other WIN-OS/2 applications
 (whether launched from the same WIN-OS/2 VDM or not) can create their own main
 windows (see step 4), or the existing applications can create secondary
 windows which can extend beyond the original window's co-ordinates. Corel
 DRAW! for Windows creates a main window with a tool bar which hangs below the
 bottom of the window if resized, resulting in a non-rectangular window.  OS/2
 2.0 handles such exceptions without a problem.

 If an OS/2 application window is created, moved or resized to overlap a
 WIN-OS/2 application's window (see step 5A) the PM screen device driver will
 cause a "white hole" to be created in the "virtual" screen space of the
 WIN-OS/2 session (step 5B).  This causes the WIN-OS/2 application to avoid
 painting the part of the window that has been "covered" by the OS/2
 application, and restrict repainting to the portion which is still "visible"
 under or around the "white hole" (see step 5C).  If the OS/2 application
 window is subsequently closed, moved or resized, the screen drivers
 communicate again to change the size of the "white hole" (in a similar way
 that the co-ordinates of the "black hole" are changed in step 3B).

 The use of "black" and "white" holes means that WIN-OS/2 and OS/2 (including
 DOS) application windows can overlap each other normally, without one
 incorrectly painting over the other. The two screen drivers keep a record of
 each other's state without affecting any of the OS/2 or WIN-OS/2 applications.
 This means there are no significant compatibility or programming
 considerations.  Since the PM screen device driver is always aware of the
 changes made by WIN-OS/2 applications' windows, there is no impact to OS/2
 applications, and likewise for WIN-OS/2 applications which create, move,
 resize and destroy windows in the normal way.  Performance is good, because
 communication is at a low level between screen drivers, not an API mapping
 layer, and compatibility is excellent because no fundamental changes occur to
 either the Windows GDI or PMWIN (the main window-creating components of
 WIN-OS/2 and PM respectively).  And as far as the user is concerned - it just
 works, minimising the difference between DOS, Windows and OS/2 applications.
 In fact, it achieves the aim of "seamlessness" by making applications behave
 in similar ways, whether DOS, Windows or OS/2 applications.  To the user, it
 appears easy, but the technical accomplishment behind it is considerable.


ΓòÉΓòÉΓòÉ 8.3.5.2. High resolution support ΓòÉΓòÉΓòÉ

At General Availability time in March 1992, Seamless drivers were only
available in VGA. This means that the whole system (including PM) must run in
VGA if Seamless operation is required. The installation program gives users
with 8514/A or XGA adapters the choice between high resolution WIN-OS/2 in full
screen, or Seamless in VGA.  Remember that the choice also affects the
resolution PM appears in.  This choice will become redundant once Seamless
drivers for resolutions higher than VGA appear.  Drivers for XGA and SVGA will
become available by the end of 1992 (see OS/2 1992 developments ).

Since OS/2 2.0 shipped in March, IBM and other vendors have continued work on
drivers at resolutions higher than VGA.  Drivers for XGA and some SVGA chip
sets will be made available in a service pack by the end of 1992, rather than
than waiting for a new version of OS/2.  It is to be remembered that to enable
Seamless operation, both Windows and PM screen drivers need to be modified, for
each resolution.


ΓòÉΓòÉΓòÉ 8.3.6. Clipboard/DDE ΓòÉΓòÉΓòÉ

An important benefit of the Windows environment is the inter-application
communications it offers to Windows applications, allowing them to share data.
The two most common methods for achieving this are via the clipboard, and
Dynamic Data Exchange (DDE).

The Windows clipboard, like PM's clipboard, usually allows applications to
share data on a "once only" basis.  Data is "cut" from one application to the
clipboard, and "pasted" from the clipboard into another application.
Applications that support the clipboard sometimes allow a link to be set up
between applications, using the same or similar commands, and that link is
usually handled via DDE.  DDE is a message-based protocol allowing applications
to pass information back and forth, updating items as they choose.  For
example, an information feed like a stock market ticker, can be linked via DDE
to a spreadsheet, and update it with the latest information as the data
changes.

Both clipboard and DDE are supported for Windows applications in OS/2 2.0.
Since OS/2 already supports both of these functions (OS/2 1.3 provided similar
functions for OS/2 16-bit applications), it is mainly a matter of integrating
the Windows support within OS/2 so that Windows and OS/2 applications can
access the same function.

The way in which this is done in OS/2 2.0 is quite similar for clipboard and
DDE. Each requires one protected mode (OS/2) program acting as a "server" for
messages between applications.  Also, in each VDM running a Windows
application, a pair of applications needs to be running:  a modified version of
the Windows clipboard viewer program for clipboard, and a "ServerAgent" program
for DDE.  The ServerAgent, which is started when the VDM is started, takes DDE
messages from the Windows application and routes them to the DDEServer and
receives messages from the DDEServer and passes them to the application running
in the VDM.

Clipboard and DDE are also available between applications running in the same
VDM. This works in exactly the same way as today under DOS/Windows; the local
VDM-based clipboard or ServerAgent programs are not needed unless clipboard and
DDE are required outside the VDM.  Users can also specify that their clipboard
and DDE is local to that VDM only, or "public" to the whole system.  If sharing
between Windows and OS/2 applications is not required, the clipboard should be
kept "private", to improve overall performance.

The result of this is that clipboard and DDE are supported in OS/2 2.0 between
Windows applications, and between Windows and OS/2 applications. DOS
applications can also participate in clipboard sharing. Thus, there is a
consistent way of sharing text and graphical data between DOS, Windows and OS/2
applications.


ΓòÉΓòÉΓòÉ 8.3.6.1. OLE ΓòÉΓòÉΓòÉ

Object Linking and Embedding (OLE) is a mechanism created by Microsoft and
endorsed by other vendors, to extend the data sharing currently possible in
Windows. It is intended to support the creation and editing of "compound
documents", where elements may come from a number of different applications,
and still be editable by the source application, even when linked in another
document or application.

Several ISVs are intending to support OLE, but today only a minority of
applications actually support it. Examples include Microsoft Excel version 3.0,
and Lotus Notes version 2.0.  Windows 3.1 is expected to simplify the enabling
of this function, because it includes the necessary support in the product, but
applications still need to be rewritten to take advantage of it. Therefore, OLE
is more of a potential standard in the Windows world, than a current,
widely-used one. In addition, it has some technical limitations which preclude
its widespread use in a networked environment in its current form.

Microsoft had previously announced their intention to provide OLE libraries for
OS/2 in mid-1991, but no toolkit has yet been shipped.  OS/2 2.0 supports OLE
between Windows applications in the same Multiple application Windows session,
as long as the applications include their own OLE DLLs.  An example of such an
application is Microsoft Word for Windows version 2.0, which includes its own
"mini-applications" for functions like charting and drawing, and links to the
main word processing module using OLE.  Since there is not yet any equivalent
function in OS/2, OLE will currently work between Windows applications only.
IBM is currently investigating a superset of current Windows OLE function for a
future release of OS/2.


ΓòÉΓòÉΓòÉ 8.3.7. Windows 3.1 ΓòÉΓòÉΓòÉ

In April 1992, Microsoft shipped an updated version of Windows, Windows 3.1. It
offers a number of new functions, and a substantially expanded API set,
including Multimedia and Pen extensions (although the latter functions require
separate add on products).  Since OS/2 2.0 had already shipped by the time
Windows 3.1 shipped, IBM has no specific support for Windows 3.1 APIs in the
first release of OS/2 2.0, nor is it certain how important such support is.
IBM's aim is to run Windows applications, not Windows. Windows 3.1 support is
only an issue if it enables new windows applications to be developed which may
not run under the current level of WIN-OS/2.  Whether developers will build in
functions requiring Windows 3.1, will depend on how they view the risk of only
targeting part of the Windows installed base (those who have moved up to 3.1).
Microsoft promised compatibility between Windows 3.0 and 3.1, and are offering
developers the opportunity to ship the extra 3.1 function in DLLs along with
the application.  If this enables the application to run under Windows 3.0, it
should do for WIN-OS/2, by the same logic.  If developers follow this path, the
need for Windows 3.1 support in OS/2 2.0 may not be as urgent as some suggest.
Indeed, there have been very few Windows 3.1-specific applications appearing in
the first few months after the shipment of DOS/Windows 3.1. At one time,
Microsoft had announced that they would make Windows 3.1 capable of being a
DPMI client, and thus run under OS/2 2.0.  However, Windows 3.1 does not
possess this capability.

Nevertheless, IBM has the Windows 3.1 source code through the joint licensing
agreement and will continue to monitor the need for additional levels of
Windows support.  IBM is fully able to provide such support without help from
anyone else, as it has done so far with the development of OS/2 2.0. On April
6th 1992 Microsoft shipped Windows 3.1.  On April 7th, IBM showed the Windows
3.1 Program Manager running in a Seamless window under OS/2 2.0 (not the GA
version).  This was not an announcement of Windows 3.1 support, merely an
indication that it could be done. Work is now taking place on updating WIN-OS/2
support (see OS/2 1992 developments ) and is in beta test at the time of
writing.  The main part of the work is extensive compatibility testing with
Windows 3.0 applications.  The aim is to ensure that the change to Windows 3.1
level of support, does not lead to the kind of compatibility problems that were
reported in PC Week  soon after the release of DOS/Windows 3.1, and referenced
in the Windows 3.1 APPS.HLP file.  Because of these compatibility problems, and
the withdrawal of support for Windows real mode by Microsoft, it is true to
say, at the time of writing, that OS/2 2.0 runs a wider range of Windows
applications than DOS/Windows 3.1.


ΓòÉΓòÉΓòÉ 8.4. A better Windows? ΓòÉΓòÉΓòÉ

So, in conclusion, the approach taken to running Windows applications under
OS/2 2.0 has a number of benefits:

 o Compatibility: gives high compatibility with the widest range of Windows
   applications, since the applications are running under the real Windows
   code, modified only for compatibility with OS/2.

 o Performance: since the applications run under a modified version of Windows
   itself, it does not suffer from the performance limitations of a Binary
   Compatibility Layer (BCL) approach, such as was previously attempted (and
   subsequently abandoned) by Microsoft. Although single tasking scenarios may
   be up to 20% slower, multi-tasking performance is comparable to that under
   Windows and in many scenarios better, because of the superior multi-tasking
   design of OS/2. Indeed, the more the system is loaded, the faster Windows
   performance will tend to deteriorate in comparison with the same
   configuration under WIN-OS/2. Even the example quoted earlier from NSTL's
   independent benchmarking (see Performance ) shows Windows performance less
   than WIN-OS/2 even with only one background process.

 o Protection: since Windows applications can run in separate VDMs, they are
   better protected from each other, so that errant applications cannot bring
   down the system. Windows applications themselves are protected from DOS
   applications more than is possible under DOS/Windows.

 And, as we have already seen, OS/2 2.0 represents a superior environment for
 multiple DOS applications (see OS/2 versus Windows as a multi-DOS environment
 ), since there is more memory, better multi-tasking, and more protection than
 under any DOS or DOS extender.  Therefore, in being a better multi-DOS
 environment, and running Windows applications with full compatibility and
 extra protection, OS/2 2.0 is a better Windows environment overall.


ΓòÉΓòÉΓòÉ 8.5. Porting Windows applications to OS/2 ΓòÉΓòÉΓòÉ

Of course, although OS/2 can offer excellent compatibility with Windows
applications, those applications still remain Windows applications, and they
are therefore limited in the extent to which they can integrate with OS/2. For
example, full drag and drop functionality and other exploitation of the
Workplace Shell, is only possible if you write for that environment, and that
means OS/2. OS/2 applications have full access to a 32-bit API, 32-bit memory
management, and multi-threading capability, allowing the same application to be
much more responsive to the user (for example, retrieving a new file while
saving the old one, rather than having to wait with the hourglass showing, as
you might in a 16-bit, single-threaded environment like DOS/Windows.)  Minor
issues of look and feel are also different (as is apparent when the application
is run in a window alongside OS/2 applications).

Compatibility with existing Windows applications is important: but it does not
mean that users should not be offered the chance of using better, more powerful
and more responsive applications by using native OS/2 applications. Some have
tried to suggest that having a Windows application is enough, since it will run
under OS/2 anyway, and therefore one version will cover both markets.
Developers who have followed this "lowest common denominator" approach, are now
finding themselves unable to differentiate themselves from the competition, and
indeed at a disadvantage in the OS/2 marketplace.

Increasingly, users who migrate to OS/2 2.0, are demanding "native" OS/2
applications, and vendors who can only offer Windows applications running under
WIN-OS/2 are finding themselves uncompetitive if they do not supply a real
32-bit OS/2 version. WIN-OS/2 may be a "better Windows", but it is not as good
as real 32-bit OS/2 and the Workplace Shell. Therefore, vendors have
considerable incentive to write for OS/2 and not keep only to Windows support.
And over 1000 OS/2 32-bit applications are in development: more than 150
shipped within three months of the release of OS/2 version 2.0. Vendors who
have committed to OS/2, or who already have products available, include Lotus,
Borland, Software Publishing Corp., Novell, Corel Systems, Micrografx,
WordPerfect, DeScribe, ZSoft, Oracle, Gupta and Computer Associates. And IBM is
also delivering a number of applications (in addition to the systems extensions
described in OS/2 in a connected environment ) including Personal AS/2, and
ImagePlus/2.

Writing for OS/2, and in particular using the OS/2 32 bit API, positions the
software developer to take advantage of the developments in the OS/2
environment, including multimedia, distributed computing and the increasing use
of object technology (see Futures ).

However, possibly the most convincing argument for developers now, is the fact
that over one million copies of OS/2 2.0 have been shipped within six months of
its first availability, and OS/2 2.0 looks set to continue its success. The one
million mark is for many commercial developers, a sign of viability for a
platform. Ed Zander, president of SunSoft, Inc., the software subsidiary of Sun
Microsystems, was quoted in PC Week about Microsoft's views on porting its
applications to SunOS: "Microsoft tells every company that walks in there that
it won't do the ports until the architecture has an installed base of 1
million" Microsoft's Bill Gates was quoted by PC Magazine as saying he would
only consider developing for OS/2 when it shipped more than 2 million  units.
OS/2 has already passed the one million mark and is heading towards the second.
Whether the report in PC Magazine has any relevance to any future plans
Microsoft may have for OS/2 2.0 applications, is unknown.

Although the Windows and PM APIs are in some respects different, porting tools
like the Developers' Migration Kit (see below) are being developed which aid
the migration of Windows applications to OS/2, to allow them to take advantage
of OS/2 benefits.  These are tools at the developer rather than user level: the
Windows applications compatibility solution described above is a user-oriented
solution, to gain maximum compatibility with existing shrink-wrap applications
and derive some inherent OS/2 benefits like true multi-tasking and reliability;
there are also developer tools, which allow applications to be ported from
Windows to OS/2 and add OS/2 functionality in the process. Among such tools are
those being produced by IBM and Micrografx.


ΓòÉΓòÉΓòÉ 8.5.1. IBM/Micrografx porting tools ΓòÉΓòÉΓòÉ

In April 1991, IBM announced a joint development and licensing agreement with
Micrografx, Inc., a leading vendor of Windows and OS/2 applications. Part of
that agreement included IBM's and Micrografx's intention to produce a porting
toolkit to help move Windows applications to OS/2.

The Developers' Migration Kit/2, announced in July 1992, allows developers to
port applications and drivers from Windows to OS/2 with little or no code
changes.  There are tools for applications and for device drivers.  The
applications porting kit, and the device driver kit are based on the Mirrors
technology from Micrografx.  Developers can maintain a common code base between
Windows and OS/2, or OS/2 specific functionality as they port. The latter is
recommended to enable better integration with the Workplace Shell (see
Workplace Shell exploitation )  Drivers ported with the driver tools, such as
the HP Paintjet driver, are already part of the OS/2 2.0 base printer driver
suite.

This will increase the number of OS/2 applications by leveraging the Windows
application base, and make it easier for developers to participate in both
opportunities. This in turn will give the user another option to take advantage
of his existing investment, but also have a wider choice of real OS/2
applications.

The way in which the porting process takes place is similar to a product
previously distributed by Microsoft, the Windows Libraries for OS/2 (WLO). WLO
was derived from Micrografx Mirrors technology, but IBM and Micrografx are now
using a more mature version of the technology in the Developers' Migration
Kit/2.  Furthermore, the philosophy of the Developers' Migration Kit is
somewhat different to that of WLO:  the latter retained something of the
original BCL approach (see Contrast with previous approaches (BCL) ), allowing
a Windows application to run on OS/2 by emulating Windows on top of OS/2,
providing OS/2 versions of the Windows libraries the application usually links
to.  Although the porting process is similar, the Developers' Migration Kit is
designed specifically to produce applications for OS/2 2.0 (not both 16- and
32-bit as was WLO's aim), and has a number of additional tools to help optimise
the port for the OS/2 environment.  The result is likely to be better
performing OS/2 2.0 applications than were possible using the WLO approach.


ΓòÉΓòÉΓòÉ 9. Better OS/2 ΓòÉΓòÉΓòÉ

OS/2 1.3 has been widely respected and well received. Nevertheless, as well as
being a better DOS than DOS, and a better Windows than Windows, OS/2 2.0 is
even a better OS/2 than OS/2 1.3. This section will show why.


ΓòÉΓòÉΓòÉ 9.1. Compatibility ΓòÉΓòÉΓòÉ

OS/2 allows applications written for previous releases of OS/2 to work without
modification on version 2.0. The design of OS/2 always took this into account,
and provides binary compatibility not only for the commercial applications
written by ISVs, such as Lotus 1-2-3 for OS/2, but also the "line of business"
applications written in-house by various companies to support their key
business activities.  It is estimated by one independent source that as much as
$4 billion of investment has been made in such systems running on OS/2.
Compatibility with these applications is a statement of IBM's intention to
protect that investment while migrating forwards to new and better
environments.

The OS/2 design had to take account of 16-bit applications running in a 32-bit
system, and the system itself provides many services to allow 32-bit modules to
call existing 16-bit modules, thus allowing for mixed 16/32-bit applications.
This means that the mixed model gives great flexibility, both in migrating
applications from 16- to 32-bit, and also in allowing 32-bit applications to
make the best possible use of existing service routines, window classes etc,
developed for previous releases of OS/2. (See Mixed 16-/32-bit environment ).

Furthermore, the consistency of the API between 16- and 32-bit, allows
relatively easy migration to 32-bit.  The PM API in particular was designed
with 32-bit in mind, and this makes the 16- to 32-bit conversion relatively
straightforward.  Conversion can be done in stages if preferred, the mixed
16:32 model allowing a variety of approaches from recompiling and relinking, to
full rewrite for critical sections, optimising for 32-bit.


ΓòÉΓòÉΓòÉ 9.2. Graphical installation ΓòÉΓòÉΓòÉ

The user's first view of the system, at installation time, is very different
from 1.3. Instead of being entirely text-based, after the first disks,
installation is done in a graphical mode.  This is more consistent with the
main user interface, and provides better feedback to the user: a progress
indicator bar shows how far through the installation the user has got, and
pictures of disks appear at the bottom to show how many disks have been used
and how many remain.

The Install program is more intelligent; it can figure out your mouse, display,
keyboard and country setup, and offer defaults for you to choose. For those who
need more detailed control over their system, the selective install which first
appeared in 1.3 is also in 2.0, but as a graphical dialog box with check boxes
to select the options and buttons to indicate how much each item takes up on
disk, as well as a cumulative indication of the total disk space required for
the components chosen.  Among the options that can be chosen or left are the
on-line documentation, REXX, fonts, HPFS, and MVDM/DOS support.  These options
allow further selection at a more granular level.  For example, many people
install DOS support but not Windows support, since they have no Windows
applications.  Even individual utilities and applications can be selected or
not; and the size of each component is listed to help you determine whether or
not you want to spare the disk space.  This can make a difference, as the Tools
and Games "applets"  (see Applets ) take up to 5.7Mb of disk space.  But a
listing of the individual utilities and games allows you to see what each item
takes (eg games:  JIGSAW 68K, SOLITAIRE 375K; applets:  TERMINAL 1501K, PM
CHART 1159K).


Installation program - progress indicator

The user is given an easier and less error-prone way to control some of the
parameters in CONFIG.SYS, by cycling through valid options.  Once the product
is installed, further customisation is possible via the OS/2 system folder
(which contains options similar to the OS/2 1.x Control Panel). Options can be
added individually at a later point with the "Selective Install" object in the
"System Setup" folder.

For users wanting to install OS/2 over an existing DOS system, OS/2 install
offers migration of existing DOS, Windows and OS/2 applications.  If the
install program detects applications it recognises on the disk, it will offer
the user the option to put them in a folder.  This way, the system can come up
with the user's existing applications already available.  These applications
are also set up with an optimal collection of DOS and Windows settings.  System
Administrators can create their own custom database of applications to migrate
in a similar way (see Migrating applications ).

When installing over a Windows 3.0 or OS/2 1.3 machine, the program groups are
migrated into folders so that the groupings of programs are the same in the new
environment. Device drivers from either DOS or OS/2 CONFIG.SYS files can be
migrated too, as well as printer definitions from either Windows 3.0 or OS/2
1.3.

For new users, the install can give a tutorial on use of the mouse in order to
guide the user through installation.

As well as being simpler and more appealing to look at, installation is faster,
due to an enhanced compression/uncompression algorithm for unpacking files from
the disks.  Install can be done from any drive to any drive, allowing OS/2 2.0
to be installed, in future, from CD-ROM, or any other media that can be
accessed as a normal drive letter, including across a LAN if required.  In
addition, tools and services are available from IBM to assist the automated
installation of many machines.  Remote installation and systems management is a
major area of development for OS/2, but many basic tools and facilities are
here today (see Configuration, Installation, Distribution (CID) ). Most
important of all, is that OS/2 2.0 is already enabled for automated LAN-based
installation.  See the publication OS/2 2.0 Technical Compendium, Volume 5:
Remote Installation and Maintenance  (GG24-3780-00), for more details.

Such automated installation tools can substantially reduce the amount of time
taken to install OS/2 on a number of machines, since installation can take
place simultaneously on several machines without operator intervention. The
option for automated, LAN-based install, reduces objections to the amount of
time taken to install the operating system. Even in a standalone environment,
installation is straightforward, and though the number of disks required for an
OS/2 installation does mean that a manual install will usually take at least 20
minutes, it is usually one single operation to install the system, with one
reboot in the middle. Many people forget that although Windows comes on less
diskettes, it does require DOS to be installed first, causing a two-stage
installation process, and, for certain requirements, some co-ordination between
the DOS and Windows installations is required (for example, if you want to use
a mouse in a DOS window inside Windows 3.x - see Integration ).


ΓòÉΓòÉΓòÉ 9.2.1. Boot Manager ΓòÉΓòÉΓòÉ

For users who wish to retain more than one operating system on their disk, OS/2
includes a multiple boot facility (Boot Manager).  This allows different
operating systems to be placed on separate partitions, in order to select which
partition to boot at power-on or reset time.  Since OS/2 can support the vast
majority of DOS, Windows and OS/2 16-bit applications, it is not anticipated
that this will be needed by many people for booting DOS or OS/2 1.3 instead of
2.0, but instead may be used with other systems such as AIX, or as a testing
tool for developers or technical support staff.

It works by allocating a 1MB primary disk partition to a Master Boot Block
(MBB) which contains code that is always executed first at boot time and
handles further access to the hard disk.  It displays a menu allowing the user
to select the logical drive from which to start the system.  Once this logical
drive is selected, the operating system loader for the appropriate system is
loaded as normal.  New versions of FDISK and FDISKPM allow the user to select
the logical drive for use.  DOS and OS/2 1.3 have to be installed on a primary
partition on the first hard disk, but OS/2 2.0 can be booted from any partition
on any drive. This gives greater flexibility in planning installation than is
possible using DOS, or Windows, which is dependent on DOS for booting.


ΓòÉΓòÉΓòÉ 9.3. OS/2.0 - the 32-bit system ΓòÉΓòÉΓòÉ

There are a number of obvious benefits to users in working with OS/2 2.0. There
are also many benefits for developers.  Developer benefits can also be relevant
to users: anything that helps developers ultimately helps users, since it
becomes easier to write better and more powerful applications, and provide the
opportunity for applications that could not be produced before.


ΓòÉΓòÉΓòÉ 9.3.1. Why 32-bit OS/2? ΓòÉΓòÉΓòÉ

First, it is worth examining why it is significant that OS/2 is a 32-bit
system, and what benefits this can provide.


ΓòÉΓòÉΓòÉ 9.3.1.1. Better performance ΓòÉΓòÉΓòÉ

One of the most obvious benefits of a 32-bit OS/2 program is that it will
almost certainly perform faster than a 16-bit equivalent. An OS/2 32-bit
application can make use of the full 32-bit instruction set and extended
registers of the Intel processor. Some 32-bit compiled programs will also be
smaller in size because of the smaller number of CPU instructions needed to
complete certain tasks. Low level functions such as string manipulation, data
movement and pointer operations will often be twice as fast under 32-bit.

Furthermore, if the application is coded to the flat memory model, there are
none of the overheads of segmented programming, such as the need to reload
segment registers every time a different 64KB of memory needs to be accessed.
This is slow and also an inconvenience and wasted code for the developer.

The system itself provides more efficient paging than both the swapping
mechanism of OS/2 1.3, and the memory paging used in the 16-bit Windows system
(even on a 386). Applications that take advantage of the smaller memory
granularity (memory can be swapped out to disk in 4KB pages) by intelligent
organisation of code and collaboration with the paging mechanism by allocating
memory in page size units, can show a significant performance improvement.

The performance improvements that are possible depend on the changes made: they
range between 5% and up to around 40%.  An example of the improvements possible
is in the REXX interpreter, part of the OS/2 base system. Performance has been
dramatically improved since it was changed to run in 32-bit mode, as the graph
below shows:


Comparison of 32- and 16-bit performance - REXX

Even more encouraging is how such benefits can be achieved with relatively
little additional development time. since OS/2 was designed with 32-bit in
mind, migration from 16-bit has been made as straightforward as possible (see
Migration 16- to 32-bit ).

The difference between 16-bit and 32-bit can be significant, especially when it
is comparing Windows and OS/2 capabilities at the same time. DeScribe is a
graphical word processing application which exists for 16-bit OS/2 (OS/2 1.x)
and for 16-bit Windows (Windows 3.x).  The company has, in the past,
demonstrated beta test versions of its 32-bit OS/2 release (which shipped soon
after OS/2 2.0's March availability), comparing it with its own 16-bit Windows
version.  Comparisons made by Describe, Inc., show that the 32-bit OS/2 version
can be anything between 30 and 300% faster than the 16-bit Windows version, to
complete the same operation.  In addition, the OS/2 32-bit version implements
features like multi-threading which cannot be offered in the Windows version
(since Windows 3.x cannot provide multi-threading).  This makes it possible,
for example, to save one file and then start loading another while the previous
file is being saved to disk, or looking at one document while another is
repaginating.  This results in even higher perceived  performance to the user,
because the application is more responsive, and less time is spent looking at
an hourglass icon.


ΓòÉΓòÉΓòÉ 9.3.1.2. More sophisticated applications ΓòÉΓòÉΓòÉ

Applications that may need space and better ability to handle large data
objects (eg DTP, CAD/CAM, financial modelling, multimedia, database) will be
easier to develop in a 32-bit system. Indeed, some may not be possible or
feasible in a 16-bit system. In a segmented environment, programmers have to
develop their own algorithms to use multiple segments to implement a single
logical structure, which is complex and may make it difficult to achieve
performance objectives. This is another issue that may help some applications
move from the Unix environment to OS/2, since they have not been feasible on an
Intel platform till now. Also, OS/2's support for overlapped I/O enables
support for more sophisticated applications, like multimedia, where it allows
better synchronisation between audio and video.


ΓòÉΓòÉΓòÉ 9.3.1.3. Workplace Shell exploitation ΓòÉΓòÉΓòÉ

Windows and DOS applications will load from the Workplace Shell, but not take
full advantage of the drag and drop capabilities and other methods of
participating in the shell. It is possible to provide compatibility, but not
full integration, since Windows applications remain Windows applications (see
Porting Windows applications to OS/2 ).

Some of the examples of what can be achieved by integrating the application
with the Workplace Shell include:

 o drag and drop printing, and file loading

 o drag and drop installation

 o consistency of user interface with the rest of shell - ease of learning
   applications

 o registration of application objects, so they can appear as templates and
   have their own file associations

 o interaction with other Workplace Shell objects

 o more powerful user navigation: context menus, settings controls, views etc

 o on line documentation, including integration with the Master Help Index if
   required

 o shutdown notification (eg start up with same collection of views and objects
   next time - pick up from where you left off)

 Although the benefits of Workplace Shell integration do not specifically arise
 from the fact that the system is 32-bit, they can only be achieved today by
 coding to the OS/2 32-bit API. 16-bit Windows can provide very little of this
 function today.


ΓòÉΓòÉΓòÉ 9.3.1.4. Portability ΓòÉΓòÉΓòÉ

Applications written for OS/2 2.0 will be much easier to port to other 32-bit
systems like AIX than applications written for 16-bit systems, as dependencies
on processor specifics (such as the Intel segmented model) are eliminated.
Ports from other environments (Unix etc) will be easier for the same reason.
This will give the user an even wider choice of applications.

Applications written for OS/2 2.0 will also be better prepared for systems as
yet unreleased such as a future portable version of OS/2.


ΓòÉΓòÉΓòÉ 9.3.1.5. Simpler programming model ΓòÉΓòÉΓòÉ

In OS/2 2.0, there is no need to take into account the requirements of the
Intel segmented model, calling for code to be broken down into 64KB segments,
and also no need for segment manipulation when passing control between threads
or calling DLLs, for example, as is currently the case in 16-bit systems like
OS/2 1.3 and Windows. Instead, memory is allocated with a 32-bit pointer that
maps into an address space of 512MB, with no 64KB limit on the size of
individual segments. Memory can therefore be allocated in logical units
dictated by the requirements of the application rather than the constraints of
the segmented memory model. This leads not only to better performance (reduced
segment reloading), but reduced application development time (less code needed
to do the same job, since segment handling code is no longer necessary).

32-bit OS/2 coding is also simpler because there is only one memory model,
instead of the many (small, medium, huge) under the segmented application model
(represented by OS/2 1.3, DOS, Windows).

The result for the user is that powerful and sophisticated applications will
appear quicker, and some will be feasible for the first time, because they are
easier to develop. Also more programming time can be spent on providing better
function or usability rather than managing memory segments, which should also
benefit the user.


ΓòÉΓòÉΓòÉ 9.3.1.6. Exploit hardware investment ΓòÉΓòÉΓòÉ

32-bit programs allow companies to take advantage of the investment in 32-bit
hardware systems that they have been purchasing for several years. Currently,
32-bit hardware is, in most cases, running 16-bit software. 16-bit software
does not take advantage of the features of the hardware that have been
optimised for 32-bit operation. 386 machines have simply been used as "go
faster" 286 or 8086 machines, until a 32-bit system has become available to
take advantage of it. As we have seen, the benefits of 32-bit are not just in
performance, but in broadening the scope of what can be done. Waiting any
longer for 32-bit alternative systems to become available, simply increases the
length of time that the investment is left unexploited.

All in all, 32-bit equals a richer set of applications, which are faster, and
allow more choice and more function for users; in this way, developer benefits
become user benefits.


ΓòÉΓòÉΓòÉ 9.3.2. Migration 16- to 32-bit ΓòÉΓòÉΓòÉ

Best of all, migration from 16- to 32-bit OS/2 applications can often be
accomplished relatively easily. PM was designed with 32-bit use in mind, and
the design of OS/2 2.0 has taken into account the need, not only to run OS/2
1.3 applications unmodified, but also to make it straightforward to change the
16-bit OS/2 application to exploit 32-bit. In some cases, little more than a
few function call changes are required. In many cases, changes will be needed
to change from a segmented 16-bit memory management to the flat memory model of
2.0. How much work is involved here depends on how many dependencies the
existing 16-bit application has on segment manipulation. What certainly can be
said is that movement from 16- to 32-bit OS/2 will be no more difficult than
changes to other 32-bit APIs (such as a future 32-bit Windows API), when they
appear. Windows 3.x is based on an inherently 16-bit segmented model; unlike
OS/2, it did not have the benefit of being designed with 32-bit migration in
mind.


ΓòÉΓòÉΓòÉ 9.3.3. OS/2 - a 32-bit API - TODAY ΓòÉΓòÉΓòÉ

Some arguments against OS/2 rest on claims that OS/2 is not a full 32-bit
system, or that other DOS-based alternatives provide a 32-bit system today.
Such claims are based on misconception.  The essence of whether a system is
32-bit or not, does not lie in how its internals are coded, but in the benefits
it offers to users and programmers.  In fact, even to developers, the key issue
is not what the system looks like internally, but what kind of programming
interface is offered.  And, in this respect, OS/2 already offers a full 32-bit
API, which has been designed to offer the maximum ease of migration from 16-bit
(see above).  The OS/2 32-bit API enables developers to escape from the
limitations of 16-bit segmented memory management to a flat memory model, but
also offers multi-threading, advanced graphics support, and powerful
interprocess communicatons.  The OS/2 32-bit API is also enabled to accommodate
extensions like multimedia and pen-based computing.  It therefore opens up the
future path not only for multimedia and pen, but also portability to RISC, and
for increasing use of object-oriented technology, distributed networking and
other developments.

In contrast, Microsoft offers today only a 16-bit API for Windows 3.x. The only
32-bit function currently available is the sparse set of functions in the
WINMEM32.DLL, which even Microsoft itself warns, requires advanced Windows and
assembly level programming skills.  Applications coded in this way may not be
easily portable to other processors, if extensive use is made of Intel assembly
language.  Since WINMEM32.DLL is a set of eight 32-bit function calls grafted
on to a 16-bit DOS extender, the 32-bit code cannot make calls to 16-bit
Windows or DOS functions, and therefore the WINMEM32 program has to create its
own interfaces between the 16- and 32-bit code segments, with address and
parameter translation, ie the application must implement its own thunks, and
they must be implemented in assembler.  This is in contrast with OS/2 2.0,
which is designed to allow easy mixed model programming, and provides thunk
controls to move between 16- and 32-bit modules.  This makes developing 32-bit
applications much easier, and much easier to migrate from 16-bit.

Microsoft has announced that when Windows/NT ships, it will implement a 32 bit
API, referred to as Win32. Publicly available specifications of the Win32 API
show it to be very similar in principle to the OS/2 32-bit API, with few extra
features. But since Windows/NT is not scheduled to ship before the first half
of 1993 at the earliest, Microsoft has announced a subset of the Win32 API,
Win32s, will be available for developers working on Windows 3.1.  This is
understood to offer flat memory model programming (although details of the
thunking that will be required are as yet unavailable), but will not offer
advanced features like multi-threading and advanced graphics, which Microsoft
says will not be available until Windows/NT appears.  Industry commentators
have pointed out that the result of this is that developers will have to
consider three different Windows APIs:

 o Win16 (Windows 3.x)
 o Win32s (Windows 3.1)
 o Win32 (Windows/NT)
 and have to consider how they can design programs across three APIs, which can
 meet the stated Microsoft goal of scalability across the various future
 Windows offerings.

 On the other hand, OS/2 is available today, and the 32-bit API has been
 available to developers for several years now, offering all the features
 promised across the three separate future Windows offerings, in one single
 API. And the target platform has sold over a million units, several months
 before any alternative is due to appear.

 Internally, OS/2 is a hybrid 16-/32-bit system.  The majority of the system
 code (including most of the kernel, VDDs and the Workplace Shell) is 32-bit.
 Some other parts are obviously 16-bit as they aim to provide compatibility
 with older 16-bit software:  for example, WIN-OS/2 is a modification of 16-bit
 Windows code, and is therefore as 16-bit under OS/2 as it is under DOS! Also,
 OS/2 maintains 16-bit code where it has been designed to accommodate 16-bit
 modules and DLLs, offering support for mixed 16- and 32-bit code that is not
 apparent in Microsoft's stated aims for Windows/NT.  Device drivers and parts
 of the file system are also still 16-bit. Other 16-bit parts would gain little
 benefit from being adapted to 32-bit (such as the command line utilities like
 TREE and SORT). In general, OS/2's mixture of 16-bit and 32-bit code is well
 suited to the range of today's applications where 16-bit calls predominate. It
 remains to be seen how well Windows/NT will be optimised for the 16-bit
 applications which will still be the majority (especially as it will not be
 able to run any of the OS/2 32-bit applications which will comprise the
 majority of 32-bit applications when NT finally ships). As 32-bit applications
 grow in popularity, OS/2's mixture will become more 32-bit.

 But it must be stressed that the internals of the system are irrelevant to
 both users and programmers.  Programmers care about a 32-bit API:  OS/2 offers
 a shipping product with a 32-bit API; Microsoft only currently supplies a beta
 version of Windows/NT.  Users care about compatibility and performance, and
 OS/2 provides both of these within its design.  Where 32-bit can offer
 potential benefits (eg performance or future portability), the system
 components either have been moved to 32-bit or will be over time (for example,
 the 32-bit PM graphics engine and screen device drivers, which will be
 delivered by the end of 1992 as an update pack).  On the other hand, though
 Microsoft claims that Windows 3.1 has significant 32-bit code internally
 (though only when running in 386 enhanced mode), it does not offer any 32-bit
 API nor multi-threading, so the benefits of 32-bit are only partly realised.

 One of the key issues in the "32-bit" debate is portability to and from other
 processor families such as RISC. But such portability for OS/2 or Windows
 requires two things: the operating system kernel and subsystems, and the
 applications. If the API is not 32-bit, there is little point in having a
 portable kernel, since the applications cannot move without the API. OS/2 has
 a mature 32-bit API TODAY, and it has been available for over 4 years (since
 the original Microsoft OS/2 2.0 SDK). This API was designed to accommodate the
 future directions of OS/2, including portability to RISC, a promise we made
 together with Microsoft in 1989. Although Windows 3.1 contains some 32-bit
 modules internally in some of its components (eg FastDisk) some of these are
 so Intel-specific that moving them to RISC will be difficult, if they are
 attempted at all. So once again, the issue of the internals of a system is an
 irrelevance, and moreover a distraction from the real issue: the key factor in
 a 32-bit design is balancing the aims of portability and performance, but most
 of all, ensuring that applications can be delivered to exploit the system via
 the 32-bit API. Today, OS/2 delivers such an API, with features that are only
 promised for the future by Microsoft.


ΓòÉΓòÉΓòÉ 10. Workplace Shell ΓòÉΓòÉΓòÉ

The new user interface for OS/2 2.0 is one of the more obvious ways in which
the new OS/2 is better than before.  But because it is a new interface, some
aspects need some discussion as to why they are new and what benefits they
bring.


ΓòÉΓòÉΓòÉ 10.1. Why another user interface? ΓòÉΓòÉΓòÉ

The new look of OS/2 2.0 sets it apart visually not only from previous versions
of OS/2, but also from other GUI environments on Intel-based PCs, such as
Windows. To some, a new look presents opportunity; for others, who do not like
change, the difference can seem a problem. It is worth examining some of the
reasons why OS/2 2.0 presents a new look and feel, rather than just continuing
with the OS/2 1.x look.

 o Move to the future

   OS/2 is not only a system that protects past investments in DOS, Windows and
   OS/2 1.x, but is also a platform for the future. It aims to provide the kind
   of object-based interface that will be the norm in tomorrow's
   object-oriented systems, but can deliver this function today, since
   386-based platforms have the power to support it. This is the new look
   defined in IBM's Common User Access (CUA) 1991 guidelines for the
   "workplace" model. But CUA is not just a set of rules - it is based on a
   vision of how computers can really become more useful and useable. Ask your
   IBM contact about the "CUA Vision" disk-based presentation and video (see
   CUA Vision materials ), to see where the workplace model is heading in
   future, and what sort of applications can be developed.

 o Need to attract new users

   The PC marketplace is beginning to slow in growth. Vendors end up selling
   more hardware and software to the same people, and IS departments find it
   difficult to broaden the base of computer usage. That is because apart from
   the pioneers and early adopters, PCs are still too difficult to use for too
   many people. Current users would like to do more with their existing
   systems, but are constrained by the difficulties of learning so many
   different applications, each with their own unique way of working. And the
   fact that we are finding neither new uses nor new users for PCs, means that
   the return on our investment is limited, and the benefits are not being
   fully realised.

 o Focus on INFORMATION, not the computer

   Too much of today's use of PCs requires the user to know a lot about the way
   the computer handles the data. Even GUIs like Windows and OS/2 1.x are
   basically a graphical representation of the same old computer-oriented way
   of working. Instead of worrying about different and inconsistent "managers"
   (File Manager, Program Manager, Desktop Manager), with some handling files,
   others programs etc, the user can focus on the information he wants to work
   with, and let the system worry about file and programs. You can have icons
   representing a report, and have the system associate that with a given
   application (such as a word processor) so that clicking on the icon loads
   the application. In this way, programs become tools to achieve the real
   desired result - working with information.

 o 2nd generation GUI

   OS/2 2.0's user interface, and the design principles behind it, is the
   result of more than five years of analysis, prototyping and testing in IBM's
   usability laboratories.  The results of the tests indicate that an
   information-oriented user interface like the Workplace Shell is more
   productive and easier to pick up for first time users.  Once the basic
   principles are learned, even experienced users of old GUIs like Windows,
   find they prefer the Workplace Shell, since more complex tasks can be
   accomplished easier and it is more flexible.  It is an interface that builds
   on the achievements of "first generation"  GUIs like OS/2 1.x and Windows,
   and moves users on to the "second generation".


      OS/2 Workplace Shell

 o Harmonise different user interfaces

   People who have been using PCs for some time will have acquired knowledge of
   many different types of user interface: DOS applications have very few
   standards in user interface terms, and even Windows adds another dimension
   and another set of standards to learn. The Workplace Shell does not
   eliminate these differences (it must retain them for compatibility), but
   does offer a user interface layer above the individual differences, to
   provide a level of consistency and integration. For example, all
   applications, whether DOS, Windows or OS/2, can:

    - be launched from icons on a common desktop
    - appear in windows which can be sized, moved and hidden
    - share data via a consistent set of commands (Mark/Edit/Copy/Paste)
    - retrieved from the background, or closed via a common Window List The
   migration towards future object-based systems such as those based on the
   Taligent venture (see Object-oriented environments ), provides the potential
   for convergence of ideas from the Workplace Shell, Motif, and the Apple
   Macintosh desktop.

 o New, but evolutionary

   This progress can be made now without compromising compatibility with the
   past. The old ways of working with the PC can be kept alongside new ways:

    - the C:\> command prompt can be retained as an icon or even a menu item
      from the desktop context menu.
    - you can use folders just like Windows 3.x or OS/2 1.x groups, and use the
      icons within them just like programs, thus treating the Workplace Shell
      like the graphical program loader that Windows is for many users.

   This allows the user to take what he knows and apply it immediately, while
   learning new skills that will make his work more productive. This mix and
   match of new and old knowledge makes evolution towards the 2nd generation
   GUI much easier.

   The key is to provide compatibility, but not to let the past bar your way to
   the future.


ΓòÉΓòÉΓòÉ 10.2. An INFORMATION-oriented user interface ΓòÉΓòÉΓòÉ

The first generation GUIs like Windows and OS/2 1.x have been a good
introduction to the benefits of GUI for many people, but they are also a
constraining factor on the progress of the man-machine interface. This is
because the user interface design relies heavily on computer-oriented concepts
like files, programs and directories.  The user interface (UI) model is built
around various "managers": File, Print, Program and Desktop.  To navigate
through the system, the user must know about the difference between a file and
a program, about the physical layout and organisation of data on the disk, and
to understand some of the constraints this imposes (for example, you cannot put
files in a program group, only programs, but programs can be loaded from the
File Manager).  There were other usability constraints which related more to
the implementation of the user interface, rather than the design itself.  In
the Windows 3.0 and OS/2 1.3 File Managers, only one directory tree window
could be opened, even on a system with multiple drives.  The Print Manager only
interacted directly with the File Manager via drag and drop, but other
applications either could not, or implemented their own drag and drop protocol.


Development of user interface

Moreover, this style of user interface imposes an application-oriented way of
working, or an "action-object" paradigm: a user wanting to create a report will
load his word processor, then look for the file containing the report. The
ideal for the user would be to encourage an information-oriented way of
working, or one that uses the "object-action" paradigm, as this is the way we
work more naturally when away from the computer. Moreover, it is important not
to forget the computer is an item of information technology. It is the
information that the user wants to work with, that is why he uses the computer
in the first place.

The Workplace Shell does not make the user look for the word processor to
create a report, but rather allows him to click on an icon representing the
report, and automatically load the application (the word processor) associated
with it. This use of the object-action paradigm, and the focus on information,
is why the Workplace Shell is sometimes called an object-oriented user
interface (OOUI). It means that you create a letter by dragging a new copy from
a "template" (see Templates ), and regard the application as a tool to work
with the information, rather than a program which you must "feed" with data.

The new shell is designed to provide a more task-oriented, not process-oriented
way of working, allowing the user to focus on what they want, not how to do it.
The new shell will also reduce the amount of system-specific knowledge needed,
by being more analogous to the manual way of performing tasks (using the
physical desktop analogy).

Notice, however, that the new object-oriented way does not preclude the old
ways of working. If you need the C:\> prompt, it is available; if you want
folders full of program icons, which you click on to load, and then go through
the "File Open" menu to find your data, that can be done too. You can mix and
match the action-object and object-action techniques as you wish. But even with
older DOS programs, some of the benefits of an OOUI (such as clicking on an
icon representing a report, and having the system load the appropriate
application), can be realised very easily without a radical change to working
style. In fact, even if the Workplace Shell is used as a graphical program
loader, there are features in it (such as workareas) which make it a better one
than Windows (see Multi-tasking and the user interface ).


ΓòÉΓòÉΓòÉ 10.3. Workplace Shell components ΓòÉΓòÉΓòÉ

Not only do the design principles of the Workplace Shell differ from the older
GUI models, but it is also visually different, and it includes a number of new
features that did not appear in previous versions of OS/2.


ΓòÉΓòÉΓòÉ 10.3.1. User interface elements ΓòÉΓòÉΓòÉ

In this section we will look at some of the user interface elements that
contribute to the new look and feel.


ΓòÉΓòÉΓòÉ 10.3.1.1. Desktop ΓòÉΓòÉΓòÉ

If you are familiar with OS/2 1.x or Windows 3.x, the first thing you will
notice about OS/2 2.0 is that there is no obvious Desktop Manager, Task List or
Groups. Instead, the screen represents your desktop, and everything on the
desktop is an object - files, devices, programs etc. This means the desktop is
the background of activity, and items can be placed on the desktop or in
folders - in fact, anywhere you want; there is no restriction on where icons
are placed as there is in Windows or OS/2 1.x. This means you can have either a
"tidy" or a "messy" desktop according to the way you work.  Although the
desktop is meant to give you a visual association with a familiar idea (your
own desk), the Workplace Shell desktop is not meant to be exactly the same as
your real desktop; it offers a bit more than your real desktop.  After all, if
the computer only did the same things as you could do manually, why use a
computer at all?


ΓòÉΓòÉΓòÉ 10.3.1.2. Objects and folders ΓòÉΓòÉΓòÉ

The items on the desktop are objects: files, programs, devices (such as disk
drives, the shredder and printers). Objects reside in folders or on the desktop
(which is actually just the highest level folder). Folders are used instead of
group windows, and are more powerful and flexible. Folders can contain any
object, including other folders (again, just like the physical desktop), and
can group items according to a given project or activity (features like
workareas take this even further - see Multi-tasking and the user interface )
You can also have more than one view of a folder, allowing you to look at the
same information from different perspectives ; a simple example is in the
Drives object, which lists the files by drive and directory; this allows
multiple simultaneous views - Tree, Details, Icon views - of the same
directory.

Each object is visually represented by an icon.  You work with objects by
direct manipulation  - ie by pointing at it with the mouse (see below).  Notice
that sometimes only the terminology is different: what OS/2 2.0 calls a
"Program object", Windows and OS/2 1.x might have called a "Program reference"
or "Program icon".


ΓòÉΓòÉΓòÉ 10.3.1.3. Direct manipulation ΓòÉΓòÉΓòÉ

Direct Manipulation is the act of working with an object by pointing at it with
the mouse, double clicking to load it or open it, or dragging it somewhere
else. Since most older user interface models worked by an action-object
paradigm, experienced computer users are used to a certain level of indirection
in using a computer (ie you go through a menu to invoke a command to work on an
object). But the Workplace Shell allows users to work with objects more
naturally, as they would on a real desktop - directly. So, although experienced
users may be tempted to think of direct manipulation as a gimmick, it is in
fact a much more natural, consistent, and, in most cases, effective way of
working with the system.

A specific example of direct manipulation is drag and drop. This is where one
icon is "picked up" with the mouse and moved somewhere else, often to another
icon or folder.  Note that this use implies that objects can be programmed to
understand what it means to have something dropped on them, or for them to be
dropped on something.  In fact, there are APIs supplied for programmers to set
the behaviour of their own icons (eg for selection, dragging and dropping).

Use of these APIs allows greater consistency between the shell and
applications, and also greater integration.  Developers can now register their
objects (ie applications) with the system and have them used as an integrated
part of the system.  This all results in a more powerful and consistent
interface for the user.

Although Windows 3.x offers some direct manipulation facilities and some APIs,
its use in the system is currently limited mainly to the File Manager.
Interaction between different parts of the system is therefore more limited
than in OS/2 2.0, compromising the benefits of consistency.


ΓòÉΓòÉΓòÉ 10.3.1.4. Descriptive names ΓòÉΓòÉΓòÉ

Objects and folders can be given any descriptive name.  For example, the user
may have a folder called "Annual Report to the Shareholders", which may contain
an icon called "Shareholder Report Draft 14 dated 6th March". This may be a
document created using a Word Processing program.  Another icon may represent a
spreadsheet containing the latest financial results.  Notice that icons can
represent data files, and to edit them, the user can simply click on the object
to invoke the application that created that file, and edit it further.  Even
though files are physically stored by their old 8.3 file names (at least using
the FAT file system), they can be represented on the desktop or in a folder by
the more descriptive long name. It is easier to see that "Letter to Joe" would
be more meaningful to any user (even the creator of the file!) than
LJB0905.TXT. This feature is implemented at the file system level, so that even
data files relating to old DOS applications can be given long names in this way
- applications do not need to be rewritten.

The use of descriptive names is in keeping with the principle of allowing the
user to focus on the information, not the computer's way of working. In this
way, OS/2 offers more fexibility than Windows, in which the computer-oriented
way of working still shows through in the retention of 8.3 file names, despite
the graphical veneer on the surface.


ΓòÉΓòÉΓòÉ 10.3.1.5. Associations ΓòÉΓòÉΓòÉ

Associations can be created between files and programs, on a file-by-file or
wild card basis.  This means that simply by double clicking on a data file, it
can be loaded into the associated application. OS/2 applications can also
create their own file types and associations which are created automatically
when the program is installed (DeScribe and Excel for OS/2 are just two of the
applications that do this already).  Associations can also allow a data object
to be dropped on a program icon and have the program loaded with the data file.
Multiple associations can be created per object.


ΓòÉΓòÉΓòÉ 10.3.1.6. Shadows ΓòÉΓòÉΓòÉ

Since object icons can be placed anywhere on the desktop or in folders, this
flexibility encourages different arrangements of programs, data and devices
into "projects". This may mean that the user wishes to place a given object in
more than one folder. Instead of physically copying an object from one folder
to another, which can waste disk space and also cause maintenance problems if
the object is subsequently changed, the Workplace Shell allows the user to set
up a "shadow" of that object. (Apple Macintosh users will be familiar with the
idea which they call an alias.)  The shadow is linked to the original object
such that changes in the original are rippled through to the shadows.

Shadows allow different uses of the same object, and allows work to be
organised without regard to the physical location of data (they are
particularly useful for working with data or devices located on a server). In
this respect the combination of folders and shadows is much more powerful than
the use of group folders and specially created directories in Windows or OS/2
1.x.


ΓòÉΓòÉΓòÉ 10.3.1.7. Templates ΓòÉΓòÉΓòÉ

Templates are a means of easily creating new objects. Most objects can be
defined from an existing type, or template. The system provides templates for
the common objects such as data files, program objects, folders, printers and
so on. For example, program objects are created by dragging a program template
from the Templates folder, and entering the information about the program
executable and working directory.

But users and programmers may define their own templates. Programmers can
create new file types (eg a Customer Invoice) and define templates via their
own applications. Users can create templates themselves. For example, a "memo
pad" template can be created, to use to create new memos, each of which may be
automatically associated with a chosen word processor, and would contain a
department logo, and headings for the "To:", "From:" and "Subject" parts of the
memo.  Or a chart template could be created, so that each new chart created
inherited the default characteristics: a logo and given fonts and colours.
Since many business processes are repetitive, templates match many users' work
very well. Any kind of information that has the same basic structure in each
instance, and only the specifics beneath the "headings" change, is suitable for
creating templates. Templates provide a consistent way of creating new objects,
whether data, program, folder or device.


ΓòÉΓòÉΓòÉ 10.3.1.8. Pop-Up menus ΓòÉΓòÉΓòÉ

Clicking with Mouse Button 2 on an object's icon, or on an open folder,
displays a menu of options to work on the object. These pop-up menus display
only the actions appropriate to the current state of that object. This reduces
screen clutter and increases ease of use by eliminating redundant or
inapplicable options. This menu can be customised by the user (for example, to
change the application loaded from the "Open" menu, or to add user-defined
commands).

The use of Mouse Button 2 is one example of the UI innovations that has
received some criticism in the computer press, though it is not clear why.
Indeed, it is somewhat ironic that when Borland's Quattro Pro for Windows was
reviewed in beta test, one reviewer praised its' use of Mouse Button 2 as a
"Property Inspector". In fact, the Property Inspector provides very similar
functions for a spreadsheet or graph element (otherwise known as an object!) as
the Workplace Shell's pop-up menus do for object icons. While it is likely that
Borland's UI designers came up with the idea independently, it is strange that
what is a virtue from one vendor can be criticised in another. It is an
illustration of how perception, rather than objective evaluation, is a danger
when considering user interface design. (At least there is now the potential
for some consistency in the use of Mouse Button 2 to work on an individual
object - previously it was not used at all under Windows or OS/2.)


ΓòÉΓòÉΓòÉ 10.3.1.9. Visual Clues ΓòÉΓòÉΓòÉ

It is important, for the user's comfort and satisfaction, that clues are
supplied to aid learning and provide a context for what the user is doing. A
major principle in the Workplace Shell is to provide visual feedback where
possible, to keep the user informed about what is happening. These are often
ignored by the casual reviewer, but they contribute to the usability of the
system. Among the examples of such visual clues are:

 o change of mouse pointer between clock icon, normal pointer, I-beam for
   editing, according to the context

 o half-toned icon during copy of object (as opposed to normal tone for a move
   operation)

 o a line drawn between a shadow and its original during the shadow operation

 o a box drawn round an object which would be the target of a drag-drop
   operation

 o shading behind the icon of an object that is in use

 o "no-entry" sign on an icon when it cannot be dropped on a given object

 o highlight of the object or objects (by darker shading) which are currently
   selected (and for which the current pop-up menu is valid)

 These visual clues are more widespread and more subtle than in less
 sophisticated GUIs such as Windows, where it is sometimes difficult to
 determine the context of an operation or an object, because of the lack of
 visual clues. (Consider, for example, how the new user reacts to an icon in
 the Program Manager and another, for the minimised application, at the bottom
 of the screen, with no apparent difference between them, yet they behave
 differently.)


ΓòÉΓòÉΓòÉ 10.3.1.10. Consistency ΓòÉΓòÉΓòÉ

One of the most important aspects of the Workplace Shell is its consistency.
Not only does it provide a consistent means of loading programs from different
origins (DOS, Windows, OS/2) and make them work together, but it also provides
a standardised interface to different tasks, through the use of drag and drop.
For example, OS/2 allows drag and drop to be used for copying, deleting and
printing a file, where DOS uses three different commands (COPY, ERASE, PRINT),
each with their own set of parameters. As stated before, it also provides a
consistent interface (Mark/Edit/Copy/Paste) to sharing data between
applications, whether DOS, Windows or OS/2 applications. And drag and drop is
applied to many other actions throughout the shell, such as setting colours and
fonts.  This consistency is reinforced when using programs that integrate with
the Workplace Shell and use the same manipulation techniques (see Workplace
Shell exploitation ).  The consistency of the Workplace Shell (where drag and
drop are pervasive) can be contrasted with the rather superficial use of such
techniques in Windows 3.1.  Consistency is not achieved where drag and drop can
only be done from the File Manager, and not throughout the shell.

Consistency means that not only is the environment easier to use, but new
actions are learned quicker, often by experimentation. In fact, the key to
judging a user interface is not how easy it is to do something in an hour or a
day (after all, no user interface is completely intuitive), but what extra can
be achieved after the basics have been learned, and how easy it is to do more.


ΓòÉΓòÉΓòÉ 10.3.1.11. Flexibility ΓòÉΓòÉΓòÉ

The user has complete freedom to set the look and behaviour of the shell.
Colours, fonts and even background images can be set for the desktop, and for
each folder individually. Icons and descriptive text can be set for each
object, and even the behaviour of objects and their windows (such as whether a
window is hidden or minimised to the desktop) and the use of mouse buttons can
be customised, where appropriate on an object-by-object basis. This flexibility
is important, because users rarely agree on what is preferable. The Workplace
Shell reinforces the truth that the PC is a Personal computer.


ΓòÉΓòÉΓòÉ 10.3.2. Controls ΓòÉΓòÉΓòÉ

As well as providing a different way of working, the new look and feel of the
Workplace Shell is established by a number of new user interface controls,
including the following:

 Container      described above as folders, used to logically group objects on
                the desktop. It can provide multiple views of the objects
                (icon, text, tree, details).

 Notebook       an easy way to navigate through a complex dialog. It looks like
                the paper notebook you may use at your desk. It supersedes
                separate dialog boxes by providing multiple pages, selectable
                by tabs. The notebook control is used to allow the user to
                tailor the settings of each object.

 Slider         allows the user to select a quantity from a range of possible
                values, by using a control very similar in appearance to that
                found on many electronic devices - a "sliding" button.


  Container


  Slider


  Notebook

 There are also standard dialogs for open and save file, and font selection.
 All of these controls have programming interfaces, so that developers can use
 them in their own applications, to allow a common look and feel between
 applications and the shell.


ΓòÉΓòÉΓòÉ 10.3.3. Applets ΓòÉΓòÉΓòÉ

OS/2 2.0 also ships with a number of mini-applications and utilities,
("Applets") which give some basic functionality to get started immediately, as
well as acting as a learning aid, particularly for manipulating objects with
the mouse.  (They also provide a bit of fun!).  These range from productivity
applications like an editor, simple spreadsheet, calendar and card file, to a
charting program and terminal emulator.  There is also a utility that allows
the user to search through the disks for files matching a file specification or
even a given item of text.  Of course, there are also a number of games
including an OS/2 version of Solitaire that allows you to cheat if the game is
not going in your favour!

Applets are not intended as full function applications, but as a means of
getting productive use of the system even without installing extra software.
However, many of them are powerful enough in their own right to serve the
occasional user of, for example with PM Chart, a charting package, without
needing to invest in more software. They help to make the system appealing to
both the first time and the less experienced user.


ΓòÉΓòÉΓòÉ 10.3.4. Extra facilities ΓòÉΓòÉΓòÉ

There are a number of extra features contained in the shell to help overall
productivity, or improve ease of use:

 System Setup             This object allows the system to be easily configured
                          and changed to suit the individual. Not only does it
                          contain options for installing new features or adding
                          drivers, and for setting colours and fonts, but also
                          for modifying some of the default behaviour of the
                          system (eg whether windows are hidden or minimised to
                          the desktop; whether clicking on an icon creates a
                          new instance or retrieves a running instance of a
                          program; whether to prompt when deleting an object,
                          and so on).

 Drives                   This object replaces the File Manager from previous
                          releases. It provides similar function to the OS/2
                          1.3 File Manager. It has a multi-threaded design to
                          give good performance even in large directories. It
                          is no longer restricted by the Multiple Document
                          Interface (MDI) design of the OS/2 1.3 File Manager
                          (which is still evident in the Windows 3.1 File
                          Manager), but instead creates a series of modeless
                          (**) windows, which can be moved wherever the user
                          wishes. Drives offers all of the function commonly
                          used by the File Manager in either Windows 3.x or
                          OS/2 1.3, with the addition of greater flexibility in
                          certain operations.  For example, in keeping with the
                          rest of the shell, it offers different simultaneous
                          views of any drive or directory, either icon view,
                          tree view, or details view (the latter lists file
                          size, creation date, and other details).  Since the
                          windows created by the Drives object are just like
                          any others in the shell, files can be dragged between
                          the desktop and different directories, and to the
                          printer or any folder.

 Printers                 The ease with which OS/2 handles printing (with drag
                          and drop) is one of its strongest features, but
                          equally impressive is the flexibility of printer
                          setup and customisation of settings. Different print
                          objects may be set up, not only to represent each
                          physical printer, but also to represent a particular
                          combination of settings: for example, you can set up
                          the same printer to print portrait Times Roman
                          (represented by one icon, which you can give a
                          descriptive name such as "Portrait - for letters")
                          and create another icon to represent the same printer
                          running in Landscape mode with a small font for those
                          wide spreadsheet reports (to which you give another
                          name).  Both these printer objects can be kept on the
                          desktop or in a given folder, and print output can be
                          directed to either according to the results required.

 Convenience features     The shell also includes several features for greater
                          user convenience. The user can set his own background
                          ("Wallpaper") for the desktop, or any folder, as well
                          as a keylock security feature (blanks the screen and
                          locks up the keyboard and mouse after a
                          user-specified period).  The desktop layout
                          (positions of folders, applications loaded etc), can
                          be autosaved at shutdown and restored when next
                          starting the system. The workarea feature (see
                          Multi-tasking and the user interface ) makes it
                          possible to do this on a folder by folder basis. This
                          means that different projects (or even different
                          users sharing the same PC) can be kept logically
                          separate.  All of these features help make the system
                          easier and more enjoyable to use.

 Tutorial                 The default action after installation is to start the
                          tutorial, so that the first time user is taken
                          through the key elements of using the Workplace
                          Shell. The tutorial is highly recommended, even for
                          an experienced user of DOS Windows, or OS/2 1.x, to
                          familiarise oneself with the differences from the
                          previous environment. The tutorial can be revisited
                          at any time; it usually resides in the Information
                          folder.

 Online Help              The tutorial is just one of the items of information
                          that the OS/2 user has available. As well as
                          context-sensitive help being always available through
                          the F1 key, there is also a Master Help Index, which
                          gives a "how to" reference guide to using the system.
                          The Command Reference from version 1.3 is also
                          retained, and there is in addition, a glossary of
                          terms. The ability of the shell to keep multiple
                          modeless windows open, allows the help text to remain
                          on screen while an operation is performed, to guide
                          the user through the process.


                                                    Master Help Index

                          The Master Help Index and Glossary use a variety of
                          techniques to present information to the user:  text
                          in different colours and fonts, hyperlinks and even
                          pictures.  The Help facility also includes an
                          indexing and searching system, to help users find the
                          help they need.  All of these facilities are open to
                          the OS/2 developer as well, using the Information
                          Presentation Facility (IPF).  This allows online help
                          to be created very simply from text files containing
                          a tag language.  New functions in OS/2 2.0 include
                          the ability to predefine the help window size and its
                          position relative to the parent window; multiple help
                          pages (windows), called viewports; support for
                          multiple fonts, and easy setup of tables of
                          information; "tear off" help pages, allowing a user
                          to retain the help on screen as he follows an
                          example; and hypergraphics - the ability to click on
                          a graphic and be linked to text or more graphics.

                          All of these facilities are available to application
                          programmers, so that on-line help for applications
                          can be created to have a consistent look and feel
                          with the rest of the shell. Some developers are
                          creating on-line guides for their applications, and
                          by placing them in the Information folder on the OS/2
                          desktop, creating an "on-line bookcase".

                          In fact, the IPF facility can be used even more
                          widely than just online help for a program; in IBM it
                          is used as a general information delivery tool, for
                          online documents and reference guides - sometimes it
                          can be easier to use the computer to search for
                          information and then browse or print it, especially
                          if (as with most reference information) there are a
                          lot of cross-references.

                          One of the help items added after feedback from the
                          OS/2 beta test program was the "Start Here" object.
                          This was in response to customers who asked that the
                          shell provide the user with a visual focal point, in
                          case, looking at a desktop with no open windows and
                          no menus, he became confused and did not know what to
                          do next. The Start Here object allows a first time
                          user (or an occasional user) to find a focal point to
                          go and retrieve information about common operations.
                          It is not a replacement for the help system, but an
                          easy starting point to find out more.


ΓòÉΓòÉΓòÉ 10.3.5. Adobe Type Manager (ATM) ΓòÉΓòÉΓòÉ

One of the most important aspects of a graphical environment is, of course,
that it continue to handle text well, and provide the benefits of different
fonts and typefaces. OS/2 2.0 continues the innovation of OS/2 1.3, in
including the Adobe Type Manager (ATM) as an integrated part of PM. ATM
provides scalable font technology, to display and print high quality type on a
variety of screens and printers (not just PostScript printers, but laser
printers, inkjets and even dot matrix printers).  ATM is closely related to
Adobe's PostScript printer language, and both use the same Type 1 font format.
This means that companies with an investment in PostScript on printers or on
other platforms (such as Macintosh, AIX, VAX/VMS and IBM System/370) can be
assured of a compatible use of fonts in OS/2.  ATM is a widely used font
standard, with over 12,000 fonts available and over $4 billion invested.  It is
under consideration as an ISO standard.  Indeed, for SAA systems, Type 1 is the
standard font format, and included in OS/2 2.0 are 13 Type 1 fonts from 4
families (Times Roman, Helvetica, Courier and Symbol) that will be implemented
as "core fonts"  across all SAA platforms.  Any of the 12,000 fonts available
in Type 1 format can be installed and used with OS/2 applications, via the Font
Palette.

ATM allows OS/2 applications to render fonts in any size on the screen and
printer, retaining the high quality of the typeface. It allows WYSIWYG (What
You See Is What You Get) between screen and printer, which is important not
only for Desktop Publishing, but even for word processing and spreadsheets. ATM
is also available for DOS/Windows 3.x as a separate product, ATM for Windows,
but OS/2 includes this utility at no extra charge in OS/2 2.0, so that users
running Windows applications may take advantage of Type 1 fonts in their OS/2
and in their WIN-OS/2 sessions. However, in OS/2 it is not a separate utility,
but an integral part of the PM system. OS/2 applications can use Type 1 fonts
without any changes to the applications.

Windows 3.0 had no in-built scalable font technology, and ATM for Windows was a
popular product in that environment. However, in Windows 3.1, Microsoft
introduced their own proprietary font technology, TrueType. This is not
available on other platforms, except for Apple System 7, and according to
Microsoft has 600 fonts available (compared to Type 1's 12,000 or more). OS/2
has the ability to include support for other font formats such as TrueType,
through an open font interface which is available to font providers; such
support would usually be provided by the owner of the technology (in this case
Microsoft). This would allow TrueType support to be provided in OS/2 in an
integrated way, like ATM, if Microsoft wishes to expand the platforms on which
TrueType is available. OS/2's aim is to provide open font support, not be tied
to a proprietary font technology.

In summary, the benefits of using ATM and Type 1 in OS/2 include:

 o better quality screens and printouts

 o WYSIWYG between screen and printer

 o improved output even on less expensive printers

 o wide choice of fonts

 o investment protection in Type 1 fonts and PostScript

 o a compatible font technology between OS/2 and WIN-OS/2

 o integrated font technology available to OS/2 applications without change

 o font portability to other platforms (Macintosh, VAX/VMS, AIX, S/370)


ΓòÉΓòÉΓòÉ 10.3.6. LAN-independent shell ΓòÉΓòÉΓòÉ

As well as being a powerful and easy interface for working with data held
locally, the Workplace Shell has a degree of "LAN-awareness" built in. Although
it does not include requester code in the base system, the Workplace Shell is
able to recognise the presence of network requester software such as the OS/2
LAN Requester for OS/2 LAN Server, or the NetWare requester for OS/2. It
provides an API which other network providers can write to, to integrate more
fully with the Workplace Shell.  In this respect, it is not tied to any single
LAN system, but can provide a graphical view of data held on different networks
- it is "LAN-independent".

OS/2 has provided access to multiple LAN systems at the same time (eg NetWare
and OS/2 LAN Server) since OS/2 1.3: not only does it handle the concurrent
protocols required (eg NETBIOS, IPX etc) but now, in OS/2 2.0, can offer a
graphical view of network resources (files, printers etc) consistent with the
rest of the shell.  By providing the same constructs for remote as for local
data (folders, icons, printer and file objects), data can be moved between one
folder and another, without the need to know the precise location of the data
or which server software is running.  This makes access in multi-vendor
networks much easier.

Among the features it provides are:

 o ability to login/logout to network servers through a graphical dialog

    - this includes presenting an appropriate login dialog (if necessary)
      before a network object can be accessed; this means that, for objects
      that have specific login requirements, prompts for login are displayed,
      even if the main login is completed.

    - an extra item on context menus for network objects is Login or Logout

    - provides consistent login (though NOT a single login) between NetWare and
      OS/2 LAN Server - the difference between LOGIN (NetWare) and LOGON (OS/2
      LAN Server) are minimised

 o browse available servers and resources (subject to logon viewing permission)

    - A "Network" folder contains an icon for each requester installed (for
      example, one for NetWare and one for OS/2 LAN Server); clicking on the
      icon provides a view of the servers available


            LAN Server Tree view

    - shared directories and printers are given similar icons to standalone
      objects, but have a mini-network icon to distinguish if necessary, as
      shown in the folder below. This folder is from a NetWare server, but it
      is impossible to distinguish between NetWare and LAN Server - that's what
      is meant by LAN-independent:


            Folder with network resources

 o resources can be moved onto the desktop, or any folder, for easy and
   convenient access

    - servers, shared disks, files or printers can be shadowed into any folder
      including the desktop (see Shadows )

    - this is not just for the current session, but the icons representing the
      remote objects will be retained on the desktop at next boot, and the
      appropriate login dialog presented when the icon is next used

 o seamless access to network folders, files and printers

    - remote disk resources can be opened (if appropriate access privilege in
      force) to show folders and files (behaves just like the Drives object for
      local data).  Programs and data can be used and copied or shadowed from
      this network disk (without having first to assign the network directory a
      drive letter such as X:).

    - shared printers are easy to set up (prompts to install matching local
      device driver if not already installed, and sets up rest of
      configuration)

    - printer object can be opened to show queued jobs and job status (just
      like local printer), but user can only manipulate (hold, release, cancel)
      his own jobs; administrator can manipulate all jobs

    - network printer can be the default (no need for local printer to be
      defined)


  Draggingashadowofanetworkresourcetothedesktop


  Drag and drop printing on the network

 Disk and printer resources set up for use by an administrator will appear as
 drive objects and printer objects, like local resources. Thus, once a user has
 logged on, he can see a P: drive and an X: drive, if these have been set up
 for him by the LAN administrator. In addition, the user can assign his own
 drive letters and logical ports to network objects that he has access rights
 to (similar to doing a NET ALIAS command in OS/2 LAN Server).

 But the key point of the LAN-independent shell, is that all access is
 graphical, through the Workplace Shell. There is no need for the command
 prompt or for character-based menus. This helps to bridge the gap between the
 LAN and local resources, and provide a more consistent and seamless access to
 both.


ΓòÉΓòÉΓòÉ 10.3.7. System Object Model (SOM) ΓòÉΓòÉΓòÉ

One of the most significant elements of the Workplace Shell is something that
users never see - the System Object Model (SOM). SOM is an object model - a way
of defining objects to the system. It is the foundation of the object-oriented
design of the Workplace Shell. In fact, the Workplace Shell itself is built on
SOM:  Workplace Shell objects (folders, the shredder, the clock and so on) are
SOM objects.  This means that the Workplace Shell is object-oriented, not only
in its user interface, but also in the way it is built.  It is built on an
object foundation - quite literally, built with objects.

The fact that the Workplace Shell is built on objects, means that it can take
advantage of the benefits of object-oriented design: it is extendable. Suitably
written programs can add their own user defined objects or evolve them from the
base classes provided with the system. The result can be that the distinction
between application objects and system objects becomes blurred - the
applications blend with the rest of the shell to provide a seamless set of
services to the user. This is the starting point for evolution towards a full
object-oriented environment, where distinctions between applications and the
system cease to exist, and objects can be combined in different ways to
accomplish user tasks.

The way in which such objects are built in OS/2 2.0 is via SOM. SOM tools are
provided with the OS/2 2.0 developers' toolkit. SOM is not a programming
language, but a system for defining and manipulating object class libraries. It
provides a set of APIs and a run-time library to allow object-oriented programs
to be written to interface with the Workplace Shell.  In fact, SOM has a wider
scope even than the Workplace Shell objects you see on the desktop.  It is a
means of implementing object-oriented constructs, and is designed to be system
and language-independent.  This is an important feature, because most
object-oriented development environments today are language specific (eg you
can use either C++, or Smalltalk, but not mix both), and therefore it is
difficult to share or subclass objects or classes from other environments.

Note that you do not need to develop SOM objects to get a high degree of
integration with the Workplace Shell. Many features such as drag and drop are
provided in standard PM APIs.

The significance of SOM, rather, is in providing an object-based layer on
today's generation of operating system.  This allows many of the benefits of
object-oriented programming to be realised on a platform that also provides
compatibility with older applications.  As such, SOM provides the architectural
foundation today, for OS/2 to move in future towards increasing object-oriented
content. The Taligent joint venture (see Object-oriented environments ) is
another potential source of object technology.  As object-oriented development
becomes increasingly important throughout the 90s, OS/2 and SOM will evolve to
meet the need to use such techniques in developing OS/2 applications.


ΓòÉΓòÉΓòÉ 10.4. Moving from a previous GUI ΓòÉΓòÉΓòÉ

The design of the Workplace Shell has been tested for several years in IBM's
usability laboratories, and the beta test of OS/2 2.0 provided more information
on how easy it is to learn and use. In general, people who had little
experience of computers found the Workplace Shell easy to pick up and use, once
the basic principles had been explained. For DOS users who have not been
exposed to GUI before, and for Macintosh users, the transition is not very
difficult either. IBM's tests, and the evidence of the OS/2 2.0 beta test,
showed that the main category of users who encountered difficulties, were those
who had used a previous PC-based GUI, such as Windows 3.x or OS/2 1.x.

During the beta test, as a direct result of customer feedback, some changes
were made to improve the migration for this latter class of user. These
included the ability to predefine the look and feel of the shell to be more
like that of Windows 3.x or OS/2 1.x, and individual features such as the
choice of minimising windows to icons on the desktop, rather than "hiding" the
window, which is the default Workplace Shell behaviour.

In fact, though the default look and feel can appear different on first view,
most items are very familiar to the Windows or OS/2 1.x user once the
connection is made between the old style and the new:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 7. Windows 3.x and OS/2 1.3 vs. Workplace Shell          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé WINDOWS 3.X - OS/2 1.3  Γöé OS/2 2.0 WORKPLACE SHELL             Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Groups                  Γöé Folders (offers more function - see  Γöé
Γöé                         Γöé Objects and folders )                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Desktop Manager/Program Γöé None. Instead, a random "messy desk" Γöé
Γöé Manager                 Γöé assortment of objects (files, pro-   Γöé
Γöé                         Γöé grams or devices). This can be made  Γöé
Γöé                         Γöé as "messy" or as "tidy" as you wish. Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Icons                   Γöé Objects. This is an important dis-   Γöé
Γöé                         Γöé tinction. An icon now represents the Γöé
Γöé                         Γöé object (file, program or device) and Γöé
Γöé                         Γöé not a running program.  The main     Γöé
Γöé                         Γöé consequence of this is in the way    Γöé
Γöé                         Γöé minimised windows are treated        Γöé
Γöé                         Γöé (usually they are hidden, but you    Γöé
Γöé                         Γöé can choose to represent them as      Γöé
Γöé                         Γöé icons on the desktop - this can be   Γöé
Γöé                         Γöé set on a per-object basis)           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Print Manager           Γöé Now separate print objects for each  Γöé
Γöé                         Γöé printer (see Extra facilities )      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé File Manager            Γöé Now a "Drives" object for each drive Γöé
Γöé                         Γöé (see Extra facilities )              Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Control Panel           Γöé Separate objects for colour, fonts,  Γöé
Γöé                         Γöé mouse etc.                           Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Task List               Γöé Window List (also accessible via     Γöé
Γöé                         Γöé Ctrl-Esc)                            Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Menus                   Γöé Pop-up menus, see Pop-Up menus       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Minimise button         Γöé This "hides" the window rather than  Γöé
Γöé                         Γöé places an icon on the desktop, but   Γöé
Γöé                         Γöé the behaviour can be customised to   Γöé
Γöé                         Γöé iconise the window if required.      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Adding Programs         Γöé Use Templates, see Templates         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Mouse usage             Γöé Two button mouse usage. In general,  Γöé
Γöé                         Γöé button 1 selects and button 2 drags. Γöé
Γöé                         Γöé Use the Tutorial to learn more about Γöé
Γöé                         Γöé the mouse. Mouse button behaviour    Γöé
Γöé                         Γöé can be changed to suit the user      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

But in nearly every case, not only does the Workplace Shell equivalent provide
the Windows function, but it also offers more flexibility.  For example,
folders offer far more function than the simple group windows in OS/2 1.x or
Windows 3.x (see Objects and folders for more information):

 o allows data files, programs and devices to be grouped together

 o allows long descriptive names

 o colours, fonts and icons can be easily changed on a per-folder basis

 o the workarea property can be set to enable groups of applications to be
   opened and closed together
 Furthermore, much of the new function provides a powerful incentive to learn
 because of the many benefits, for example:

 Templates           A consistent way of creating new objects, whether
                     programs, data files or folders. In Windows 3.x these
                     would take a different procedure for each item. (See
                     Templates )

 Hiding windows      Although this behaviour takes some getting used to for the
                     Windows or OS/2 1.x user, the experience of the beta test
                     program suggests that most people never wish to go back to
                     the old way, in which the desktop is cluttered with
                     minimised icons. Hiding reduces clutter from the screen,
                     and the Window list (see below) is a much more effective
                     and consistent way of retrieving open windows. Tests show
                     that minimising a running program to an icon is confusing
                     for users who have not used a computer before, as there
                     are often two copies of the icon, one to represent the
                     program reference, and the other the running program, and
                     the user does not know how to differentiate between them.

 Window List         This is a more powerful tool than the Task List, as groups
                     of applications can be resurfaced, closed or tiled in one
                     step (see Multi-tasking and the user interface )

 Mouse Buttons       Since Mouse Button 2 is unused in Windows, there is no
                     comparison, except that there is a happy coincidence of
                     use between IBM and Borland in their use of the Mouse
                     Button 2 to produce a pop-up menu on a given object (see
                     Pop-Up menus )

 Flexible Desktop    Objects and windows can be placed where the user wishes,
                     and the action of the desktop is modeless - there is no
                     need to close certain windows before others can be opened.
                     There are therefore no artificial restrictions in the
                     user's movement around the desktop.

 But, even if the new function does not attract, it is not necessary to learn
 all of the new ways at once.  OS/2 provides all the old function too:  there
 is an object for the DOS or OS/2 command prompt, for those users addicted to
 the C:\> prompt; and Windows users can select a WIN-OS/2 Full Screen session
 if the familiarity of the Windows environment is required (see Full Screen or
 Seamless ).

 But the most important difference from Windows is the Workplace Shell's
 flexibility: you can put icons where you choose, not where the Program Manager
 or File Manager allow you; you can change the look or behaviour of almost any
 aspect of the system if the default does not suit you; and you can use drag
 and drop across most of the system, not just the File Manager.


ΓòÉΓòÉΓòÉ 10.5. Benefits of the Workplace Shell ΓòÉΓòÉΓòÉ

But all of the function and power of the Workplace Shell would be useless
unless it provided tangible benefits over other GUIs. This section lists some
of the advantages.


ΓòÉΓòÉΓòÉ 10.5.1. Easy to learn ΓòÉΓòÉΓòÉ

No system is totally intuitive, but the Workplace Shell offers a number of aids
to quick and effective learning. The tutorial gives most of the basic elements,
and can be revisited at any time. There are productivity applications and games
to get productive quickly, and have fun while learning. And the online help
system is comprehensive as a reference, or as immediate help when required. The
"Start Here" icon gives a focal point if you ever get completely lost!


ΓòÉΓòÉΓòÉ 10.5.2. Flexible ΓòÉΓòÉΓòÉ

Almost anything can be changed if the default does not suit. You can change
colours, fonts and background images, not just for the system as a whole, but
for each folder. The behaviour of mouse and keyboard, of how windows work, and
most other system defaults are all configurable. And the workarea principle can
make each project have a different combination of icons and folders, to suit
the job you are doing.


ΓòÉΓòÉΓòÉ 10.5.3. Personal ΓòÉΓòÉΓòÉ

The Workplace Shell returns to the principle that the PC is a Personal
computer. Its' motto could be "have it your way". A secretary's desktop can
look different from a manager's desktop, and each different from an engineer's.
You can have as many or as few icons as you wish. You can change the look and
feel to behave more like OS/2 1.x or Windows 1.x.


ΓòÉΓòÉΓòÉ 10.5.4. Simple ΓòÉΓòÉΓòÉ

Though the Workplace Shell is a powerful environment, it does not overwhelm the
user. You can start by using what you know and are familiar with (including the
C:\> prompt if you wish!), and move on to learn new function as you need it.
Much of the new function and tasks can be learned by experimentation, as the
consistency of the shell, and the visual feedback (eg "no-entry" signs where
icons cannot be dropped) allows users to teach themselves.


ΓòÉΓòÉΓòÉ 10.5.5. Compatible ΓòÉΓòÉΓòÉ

The Workplace Shell offers the old ways of working like the DOS prompt and the
Windows Full Screen. It takes nothing away. But it also provides a standard way
of running applications without compromising any compatibility. It does not
enforce a way of working with older applications that is foreign to the user.
You can either close applications in the consistent OS/2 way by double clicking
on the system icon, or use the application commands (such as / Quit for Lotus
1-2-3).


ΓòÉΓòÉΓòÉ 10.5.6. Consistent ΓòÉΓòÉΓòÉ

The Workplace Shell provides the same way of working whether your resources are
local or on the LAN. It allows you to use techniques like drag and drop
consistently across the system, where you would need three different commands
in DOS, and would be restricted to doing things from the File Manager only in
Windows.


ΓòÉΓòÉΓòÉ 10.5.7. Information-oriented ΓòÉΓòÉΓòÉ

The Workplace Shell allows users to work in a more natural way, by focusing on
the information they need to work with. There is less need to worry about the
computer's housekeeping, like files and directories. All in all, you work the
way you want to work, not the way the computer forces you.


ΓòÉΓòÉΓòÉ 10.5.8. Integrating ΓòÉΓòÉΓòÉ

Applications are loaded in the same way, data objects are treated in the same
way, whether they come from a DOS, Windows or OS/2 program. The Workplace Shell
integrates local and remote resources. The whole purpose is to present as
seamless an interface as possible to the variety of tools, application and data
that users need to do their job. in this respect, it is a unifying interface,
and reinforces the key aim of OS/2 2.0 as the integrating platform.


ΓòÉΓòÉΓòÉ 11. OS/2 in a connected environment ΓòÉΓòÉΓòÉ

OS/2 is the critical component in IBM's vision of the complete, managed,
client-server system. It is the key element which allows the PC to become the
focal point of information processing. Instead of in the past, where key data
processing was performed at a remote host, and information provided to users
from the central system, the OS/2 vision moves the PC to the centre, and places
the user in control of the information. This vision lies at the heart not only
of IBM's user interface design (see Workplace Shell ), but also of its strategy
to make OS/2 the base for an integrated family of networking extensions, that
allows OS/2 to be a completely network-aware system. This makes OS/2 the
Integrating Platform, not only for local productivity applications, but for the
other components of the enterprise system.  It is no longer realistic to view
the PC in isolation from the rest of the corporate network.


The OS/2 family of networking extensions

The systems extensions to OS/2 complete the picture of the full function OS/2,
designed to address the needs of the PC platform of the 90s, as discussed in
the section  The changing PC environment . They add to the wide application
choice, ease of use, investment protection and reliability of the base system,
by providing extensive connectivity, management tools and exploitation of the
existing corporate network. This section expands on the strengths of OS/2 2.0
as an easy-to-use productivity platform, and shows how, as a base platform, and
with its extensions, OS/2 is enabled to act as the "super client" of today, and
the future.


ΓòÉΓòÉΓòÉ 11.1. OS/2 for client-server ΓòÉΓòÉΓòÉ

OS/2 is not only today's server platform of choice (acknowledged by both IBM
and Microsoft), but the best available client.  These are some of the reasons
why:

 o Consistent Platform for both Client AND Server:  It is clear that if the
   same platform can be used for both the client and the server, then the
   benefits of consistency will lead to a much more manageable platform, with
   only one operating system to support.  OS/2 is the only operating system
   available that is consistent across client and server.

 o Multiple Concurrent Network Protocols:  OS/2's great strength in
   communications is acknowledged across the industry.  In particular, OS/2's
   multi-tasking design allows it to handle multiple communications protocols
   (eg NETBIOS, 3270, IPX, TCP/IP) with ease.  This ease of integration is in
   contrast with the problems of attempting such concurrency under DOS or
   Windows, such as lack of memory, poor multi-tasking performance and the
   instability of DOS-based multi-tasking.  In a world where heterogeneous or
   mixed-vendor connectivity is becoming the norm (a recent report estimated
   that 70% of LANs run more than one protocol), OS/2 is today's only reliable
   client choice.  At the Networld trade show in early 1992, IBM demonstrated a
   single OS/2 client machine with one Token Ring card, connected to a "wall of
   servers", which included three LAN servers, one running NetWare, another
   Banyan Vines, and another OS/2 LAN Server; a RISC System/6000 running AIX,
   an AS/400 and an ES/9000.  One client was connected simultaneously to all
   these shared resources - it was, of course, an OS/2 2.0 client.

 o Enabled for LAN-based install:  OS/2 can be installed from a server to
   multiple clients, allowing faster and more controlled installation, with the
   added benefits of greater automation.  Future tools will be available from
   IBM to ease the system administrator's job still further (see Graphical
   installation for more information on installation).

 o LAN-independent shell:  OS/2's Workplace Shell provides a graphical view of
   resources, whether on the local machine or on the LAN. Remote drives can be
   set on the LAN from products including NetWare, OS/2 LAN Server, Banyan
   VINES, or TCP/IP for OS/2, and also on host systems using Virtual Disk
   facilities in products like PC Support/400 and Workstation LAN File
   Services/VM.  The Workplace Shell gives seamless access to different server
   environments, making multiple connectivity easier to implement, and provides
   consistent access to network files and printers (see LAN-independent shell )

 o Easier to Manage: OS/2 provides the ability to allow administrative tasks
   (such as collection of local configuration data and performance measurement)
   to be run on the client while preventing excessive impact on local
   performance and usability. Such tasks are becoming increasingly important in
   a highly distributed PC client-server environment, and particularly where
   PCs are being rolled out into mission-critical usage in remote locations
   where on-site support cannot be provided. Remote diagnosis and support is
   therefore critical in such environments. But background monitoring and data
   collection cannot be achieved easily on a single-tasking platform like DOS.
   And the limitations of environments like Windows, that attempt to graft a
   multi-tasking layer on top of single-tasking DOS, are revealed when such
   systems management functions are attempted. Even if such tasks could be run
   in the background on Windows (not always the case), the lack of true
   multi-tasking would cause the background "probe" to be intrusive to the
   user's foreground activity. Only a pre-emptive multi-tasking environment
   like OS/2 can offer these benefits.

 o Supports both productivity and line-of-business applications:  Today's
   client-server environments are moving beyond the simple file and print
   sharing of the first LANs, towards applications like Lotus Notes, and SQL
   database applications, that can deliver competitive edge through enabling
   workgroup communication.  In this environment, it is important to deliver
   not only the support for in-house "line-of-business" applications, but
   leverage the investment in client productivity applications.  OS/2 2.0 is
   the only platform that delivers industrial strength reliability AND wide
   application compatibility.

 o Reliability:  This is perhaps the most critical issue of all.  Many of the
   reported problems with Windows 3.0 occurred in networking environments.  It
   is clear that although Windows 3.1 may have improved reliability in some
   areas, it has not changed any of the architectural deficiencies that cause
   its limitations in networking; most of the problems stem from the fact that
   Windows continues to run on DOS (see  Reliability and protection and
   Reliability ).  The issue can be summed up thus:  what use is it having a
   fault-tolerant server if you cannot rely on your client?

 Forrester Research's May 1992 report on the growth of the "super client" (see
 The changing PC environment ) identifies OS/2 2.0 as being a leading candidate
 to satisfy the demand for a highly protected, network-aware, true
 multi-tasking client platform, for use in "line-of-business" applications.
 According to Forrester, the "super client" role is beyond the scope of either
 Windows 3.1 or Windows/NT, and predicts for the latter "product delays...and
 bloated hardware requirements". That independent analysts should make such
 statements is not surprising, given the difference in protection between OS/2
 2.0 and Windows 3.1, and the difference in hardware requirements and
 availability of OS/2 2.0 and Windows/NT. OS/2 2.0 is the platform that meets
 the exacting requirements of the modern client platform (see The changing PC
 environment ) in an acceptable configuration, and is available today, not
 promised for the future.


ΓòÉΓòÉΓòÉ 11.2. The OS/2 family of networking extensions ΓòÉΓòÉΓòÉ

OS/2 2.0 is part of a family of products and systems extensions, which are
designed to work together.  In other environments, customers have to buy third
party software (if it is available) and hope it will all work together; with
IBM these extensions are tested together and integrated.  Here are some of the
systems extensions from IBM which complement the OS/2 base system:


ΓòÉΓòÉΓòÉ 11.2.1. Extended Services for OS/2 ΓòÉΓòÉΓòÉ

Extended Services for OS/2 is a separate product which provides communications
and database functions.  It includes Communications Manager, which offers a
wide range of connectivity and protocols (all of which can be active at the
same time ); and also provides Database Manager, a powerful client-server SQL
relational database, part of the SAA family of relational databases that
includes DB2 and SQL/DS.  Extended Services for OS/2 release 1.0 works with
both the OS/2 Version 1.3.1 16-bit base and OS/2 Version 2.0 32-bit base. This
will be an advantage in mixed 286 and 386 environments. Extended Services is
supported on a selected range of IBM-compatible PCs, not just PS/2s.

In keeping with the intention to offer modular options to customers, Extended
Services comes in two forms, which differ only in their database function:
Extended Services for OS/2 delivers Communications Manager and Database Manager
in a single package, providing an "all-in-one" complete connectivity solution;
Extended Services with Database Server for OS/2 adds the ability to create
databases on a server, and offers cost-effective client functions for DOS,
Windows and OS/2 clients.

Extended Services is a key component for OS/2's participation in the SAA
standards, particularly for communications protocols (APPC, CPI-C, and APPN)
and relational database (SQL, DRDA). It is one of the key building blocks for
the SAA co-operative processing applications of the future, both by third party
applications vendors and by customers themselves.


ΓòÉΓòÉΓòÉ 11.2.2. DDCS/2 ΓòÉΓòÉΓòÉ

SAA Distributed Database Connection Services/2 (DDCS/2) is a complement to
Extended Services.  It offers host database connectivity to an OS/2 client and,
working with Database Manager, allows DOS, Windows and OS/2 clients to access
host databases conforming to the Distributed Relational Database Architecture
(DRDA), which includes not only IBM's DB2, SQL/DS and OS/400, but potentially
third party database products too.  DDCS/2 widens the scope of the OS/2 client,
and is part of the wider SAA distributed database direction.


ΓòÉΓòÉΓòÉ 11.2.3. OS/2 LAN Server ΓòÉΓòÉΓòÉ

OS/2 LAN Server version 2.0 is a powerful platform for providing LAN services
to DOS, Windows and OS/2 clients.

Entry and Advanced levels are available.  Entry provides an economical base
system for both the 16-bit and 32-bit bases while Advanced adds features like a
high performance 386 file system (HPFS386) and additional error recovery, on
the 16-bit base.  OS/2 LAN Server 3.0, which at the time of writing had entered
beta test, will offer, among other new features, the ability to run Advanced
level function like HPFS386 on the OS/2 32-bit base. Other new features in LAN
Server 3.0 include:

 o high level of NetWare and OS/2 LAN Requester client co-existence, on the
   client desktop, and when integrating NetWare resources into an OS/2 LAN
   Server domain as externally defined resources

 o peer Services, which allows a OS/2 requester to share resources with one
   peer

 o redirected Install, delivering unattended install within the CID process

 o 802.2 Virtual Device Driver (VDD), enables DOS 802.2 applications to share
   an adapter with other DOS and OS/2 applications (this function is also
   included in NTS/2 - see IBM Network Transport Services/2 )

 o OS/2 TCP/IP coexistence via support of NETBIOS over TCP/IP, allowing support
   of a greater range of protocols

 o improved disk fault tolerance, mirroring without the need for rebooting the
   server, and mirroring of the boot drive

 o support for Apple Macintosh clients via an add-on product

 Like Extended Services, OS/2 LAN Server is supported on a range of selected
 IBM-compatible equipment as well as PS/2s.

 OS/2 LAN Server is a robust, scalable solution, from the small LAN, to the
 large and complex. It makes life easy for the user, the LAN administrator, and
 the systems manager:

 o for the user - a single view of all resources available, and automatic
   allocation of resources. Combined with the Workplace Shell, this becomes
   even easier.

 o for the administrator - the Domain feature makes management of large LANs
   much easier, and allows location-independent resource naming, making changes
   easier to implement.

 o for the systems manager  - performance and management tools, including
   integration with the SAA host-based NetView.

 OS/2 LAN Server provides excellent performance. In tests run by LANQuest Labs,
 an independent benchmarking company (report dated June 1992), OS/2 LAN Server
 Version 2.0 had the best overall performance compared to Novell NetWare 3.11
 and Microsoft LAN Manager.

 In the future, IBM plans to enhance OS/2 LAN Server towards full distributed
 function for the LAN environment, including common distributed services,
 common developer infrastructure, and open industry standards.


ΓòÉΓòÉΓòÉ 11.2.3.1. OS/2 LAN Server and Microsoft LAN Manager ΓòÉΓòÉΓòÉ

In 1989, IBM and Microsoft made a commitment to work towards greater
commonality between Microsoft LAN Manager and OS/2 LAN Server.  The original
scope of work has now been completed, and commonality has been achieved at the
API and functional level.  This means that applications can be written to run
on both platforms.  OS/2 LAN Server clients and Microsoft's LAN Manager clients
can coexist and interoperate on the same LAN.  Both clients can logon and
access resources at either or both servers.  OS/2 LAN Server and LAN Manager
utilise a common underlying security system as well, which includes common user
domains, access control and server local security. OS/2 LAN Server's support
for selected non-IBM equipment means that customers can now buy LAN Server on
both IBM and OEM machines, and also achieve consistency that way.

Microsoft has not, at the time of writing, committed support in Microsoft LAN
Manager for OS/2 2.0, either as a server or as a client, although they have
access to the OS/2 2.0 code. Nevertheless, customers using LAN Manager 2.0 may
obtain OS/2 2.0 client access to the server, using IBM LAN Enabler version 2.0
(see LAN Enabler ).

Although the current release of OS/2 LAN Server contains code licenced from
Microsoft, future OS/2 LAN Server plans (see above) have no dependency on
Microsoft, whose declared future plans for LAN Manager place little emphasis on
OS/2.


ΓòÉΓòÉΓòÉ 11.2.4. NetWare from IBM ΓòÉΓòÉΓòÉ

IBM, as an open vendor, provides its customers with the two major options for
server software: OS/2 LAN Server and NetWare from IBM. OS/2 LAN Server is an
excellent platform in an environment requiring IBM host connectivity today, and
complements the use of Extended Services, but many customers have NetWare-based
LANs, for application, historical and functional reasons. They therefore
require co-existence and interoperability between the two standards. NetWare
expands IBM's ability to offer better solutions in a mixed networking
environment, where support of diverse clients (Unix, Macintosh) are required in
addition to DOS, Windows and OS/2.

OS/2 2.0 is an excellent client for NetWare. OS/2 1.3 plus the OS/2 NetWare
Requester offered access to services on the various NetWare platforms.  For
OS/2 2.0, the NetWare Workstation Kit for OS/2 Version 2.0 includes the
requester code and utilities required for a fully functional NetWare client. A
separate product, NetWare Services for OS/2, adds to the requester code, a MAP
utility for network management.

IBM offers co-existence between LAN Server and NetWare.  With the OS/2 LAN
Requester and the NetWare OS/2 requester installed, the same OS/2 workstation
can log on to both types of server.  This allows customers to use both products
according to immediate requirements and installed base.  Greater
interoperability is planned.  One key element in achieving this is the
commitment by Novell to move NetWare to the 32-bit OS/2 base.  This will
combine the strengths of NetWare with the power of 32-bit OS/2 as a server
platform.  Novell's plans amount to a key endorsement of OS/2 as both a server
and client platform.  IBM will continue to offer interoperability with NetWare
systems as we incorporate more distributed services into the OS/2 LAN Server.


ΓòÉΓòÉΓòÉ 11.2.5. LAN Enabler ΓòÉΓòÉΓòÉ

IBM LAN Enabler version 2.0 offers the OS/2 requester, LAN Support Program and
DOS LAN Requester (DLR), identical in function to that provided with OS/2 LAN
Server 2.0, in a separate product. The package includes requesters for DOS,
Windows, OS/2 1.3 and OS/2 2.0, as well as protocol support, NDIS-compliant
network adapter drivers, LAN API support, and a VDD for NETBIOS applications.

This product will allow 286 and 386 PCs to connect to servers including OS/2
LAN Server 2.0 and Microsoft LAN Manager 2.0, and other compatible servers,
without having to buy a separate copy of LAN Server, or Extended Services for
OS/2. It also allows OS/2 2.0 client access to NETBIOS, 802.2 and NDIS
applications without buying LAN Server or Extended Services.

This enhances the function of OS/2 2.0 as a client to different networks by
providing the necessary function in a package separate from the server, at an
economical price.


ΓòÉΓòÉΓòÉ 11.2.6. IBM Network Transport Services/2 ΓòÉΓòÉΓòÉ

IBM Network Transport Services/2 (NTS/2) provides networking support on an OS/2
2.0 base, without requiring OS/2 LAN Server or Extended Services for OS/2. It
provides the LAN adapter and protocol support (LAPS) to support networking
applications on an OS/2 2.0 machine, and to enable automated installation of
OS/2 and other CID  (**) -enabled software across a LAN.

NTS/2 is a combination of:

  1. Network Driver Interface Specification (NDIS) compliant transport protocol
     and network adapter software

  2. OS/2 2.0 support for DOS programs requiring NETBIOS and IEEE 802.2 APIs,
     by providing a VDD/PDD combination for NETBIOS and 802.2. This allows DOS
     applications using a Token Ring adapter, to share that adapter with other
     DOS and OS/2 applications running on the same machine. For example, this
     allows DOS and Windows 3270 emulation programs using Token Ring to share
     the adapter with OS/2 LAN Requester.

  3. Configuration Installation Distribution (CID) enabling software, including
     a LAN CID utility (LCU) to manage the automated installation process.

 Note that the LAPS function was also released earlier in the LAN Enabler/2
 v2.0 product. NTS/2 adds to LAN Enabler/2, the CID support to allow automated
 installation of OS/2 in a LAN environment. In this respect, NTS/2 is more akin
 to the DOS-based LAN Support Program, with the addition of CID support (ie it
 provides the network transports and APIs to enable LAN support), whereas LAN
 Enabler/2 can be thought of as related to the OS/2 LAN Requester (since it
 provides command line and menu interfaces to manage LAN-based resources).


ΓòÉΓòÉΓòÉ 11.2.7. Open systems connectivity ΓòÉΓòÉΓòÉ

Although OS/2 is the SAA client platform, it is also vital that it embraces the
open systems world. IBM's strategy is to enable OS/2 and AIX in particular, to
interoperate as much as possible. TCP/IP for OS/2 is one product that provides
significant networking co-existence with UNIX-based systems, providing support
for many open standards such as TCP/IP, NFS, TELNET and X-Windows. This allows
OS/2 to extend its client capability into the open systems arena. IBM's
strategy is to link the OS/2 and open systems worlds closer together through
common systems extensions, connectivity and management tools (see AIX
interoperability )

The combination of the OS/2 2.0 base, and TCP/IP for OS/2, means that the OS/2
2.0 user can today view, on the same screen, DOS, Windows, and OS/2
applications as well as Unix applications through X terminal or TELNET.  This
widens still further the range of application support OS/2 2.0 can provide.


ΓòÉΓòÉΓòÉ 11.3. Systems management ΓòÉΓòÉΓòÉ

Connecting PCs together is only one part of the process of integrating the PC
into the enterprise system.  The more PCs are installed in a company, the
harder it is to control their installation, maintenance, problem solving and
performance tuning. IBM has proven strength in handling complex, distributed
networks, and therefore understands the importance of providing tools to help
manage these tasks.  To date, systems management for OS/2 has been provided by
two means:

 o by functions integrated directly into OS/2 and extensions like Extended
   Services (such as the First Failure Support Technology - FFST/2)

 o by separate standalone products which address a specific and distinct aspect
   of the overall task of managing OS/2 systems

 In the latter category, IBM has already produced a variety of products, based
 on OS/2, to assist various aspects of systems management.  The table below
 lists a few of them:

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  Γöé Table 8. OS/2 systems management tools                         Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé SPM/2       Γöé System Performance Monitor/2 (SPM/2) tracks key  Γöé
  Γöé             Γöé aspects of a system's use:  CPU, disk etc, to    Γöé
  Γöé             Γöé identify performance problems. This can be used  Γöé
  Γöé             Γöé in both server and client environments.          Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé NetView     Γöé an installation management tool, working in con- Γöé
  Γöé Distrib-    Γöé junction with the host-based NetView, that       Γöé
  Γöé ution       Γöé includes a LAN Download Utility to install or    Γöé
  Γöé Manager/2   Γöé upgrade software via a LAN server to             Γöé
  Γöé             Γöé LAN-connected PCs.                               Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé SAA         Γöé allows host-connected OS/2 machines to receive   Γöé
  Γöé Delivery    Γöé software updates from the host                   Γöé
  Γöé Manager     Γöé                                                  Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DCAF        Γöé Distributed Console Access Facility (DCAF)       Γöé
  Γöé             Γöé allows remote diagnosis and management, by       Γöé
  Γöé             Γöé receiving screens from and controlling the key-  Γöé
  Γöé             Γöé board of a remote OS/2 machine.                  Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

 IBM is continuing to expand on this range of management tools, and to
 integrate them more closely. IBM's long term goal is the provision of an
 architected management platform which adheres to indistry standards from
 organisations such as ISO, X/Open and OSF.

 IBM's strategy for systems management is based on the belief that in
 establishing the true cost of a PC system, the initial hardware and software
 cost is only a small proportion.  The extra costs, what many independent
 analysys call "cost of ownership", relate to issues like integration, support
 and systems management; or, as it was stated in The changing PC environment ,
 the costs of maintaining the systems should not exceed the benefits it
 provides.  With the growth in the size and complexity of LANs and
 client/server systems, planning and managing these systems has become
 increasingly difficult, time-consuming and expensive.  In a report in April
 1992, Gartner Group said that "Costs surrounding product updates represent the
 largest component of PC software life-cycle costs".  Customers are therefore
 investing a growing amount of resources into distributed systems management
 (DSM) and are demanding that they be simplified and automated.

 On October 6th, 1992, IBM responded to customer demands for solutions to DSM
 problems with 2 major announcements:

 o the IBM LAN NetView family of DSM products

 o a generalized solution for configuration, installation, and distribution
   (CID) of OS/2, its subsystems, and application software.


ΓòÉΓòÉΓòÉ 11.3.1. IBM LAN NetView family ΓòÉΓòÉΓòÉ

The IBM LAN NetView family of products is an OS/2-based platform for performing
DSM functions in enterprise-wide, multivendor local area networks (LANs).  The
LAN NetView platform provides the ability to monitor and control information
processing resources, including hardware and software, throughout an
enterprise.  Information is collected from monitored resources (managed
systems) and sent to other resources (managing systems).  The offerings allow
the management of OS/2 2.0, DOS 5.0, and DOS 5.0 with Windows 3.1 clients.

The new platform allows the LAN administrator at a workstation to access
different systems management applications using the same screen.  It provides
enhanced automation and greater integration among products to streamline such
management tasks as detecting hardware or software failures on the network -
which often require the combined efforts of users and trained personnel at both
remote and central locations.

The set of LAN NetView distributed system management applications being
developed by IBM include:

 o LAN NetView Manage, the platform product that provides system services for
   LAN NetView management applications.

 o LAN NetView Start, LAN NetView Monitor and LAN NetView Fix, three management
   applications designed to run on that platform.  They provide, respectively,
   configuration, systems performance and fault-management services.

 o LAN NetView Tie, which provides a LAN-to-NetView link for customers who
   prefer to divide management of system resources between LAN- and host-based
   products, or who prefer to centralize all management on the host processor.

 IBM is encouraging vendors to provide agents for their system resources to
 allow LAN NetView products to manage them, and is encouraging vendors to
 provide additional system management applications on this platform. Among the
 vendors who have declared their support are Novell, Microcom, Computer
 Associates and Ungermann-Bass.  Customers may also choose to implement their
 own LAN NetView compliant distributed system management applications.

 To encourage the development of third-party systems management applications,
 LAN NetView provides a set of common application programming interfaces (APIs)
 that have been accepted by key industry organizations that further standards,
 such as the Open Software Foundation (OSF) and X/Open, and accepted by IBM's
 SystemView.  One of these interfaces, named the X/Open Management Protocol
 (XMP), allows developers to create applications without having to know the
 underlying management and transport protocols, such as CMIP and SNMP.
 SystemView has adopted XMP as its Common Management Interface Protocol (CMIP),
 and the LAN NetView products are among the first management products in the
 industry to incorporate elements of the OSF's Distributed Management
 Environment (DME) technology.


ΓòÉΓòÉΓòÉ 11.3.2. Configuration, Installation, Distribution (CID) ΓòÉΓòÉΓòÉ

IBM also recognises the need to provide a generalised solution to the problem
of automated installation and configuration of multiple PCs.

On October 6, IBM announced its CID strategy.  CID is not a single product, but
a collection of processes with supporting products.  It automates the processes
of configuration, installation and distribution in the DSM environment and
dramatically improves productivity for system administrators. This allows both
standalone LAN and host-attached LAN customers to realize dramatic resource
savings by using the CID processes.

Though there are several aspects to CID enablement, its primary objective is to
provide unattended, remote installation of OS/2, its subsystems, and
application software on LAN attached workstations.  Customers with both large
and small networks will be able to remotely install and manage software such as
OS/2 or OS/2 applications from a single location, without requiring the
involvement of the desktop workstation user.  The CID process can apply to
installing not only OS/2 system code, but also supported application code. Each
system requires a physical LAN connection, but is not reliant upon a file
server like OS/2 LAN Server or Novell NetWare for the distribution mechanism.

The installation process is performed by an individual who initiates the
installation process at their workstation and performs other tasks such as
removing/replacing diskettes when prompted and rebooting the system when
prompted. This individual would not be required to know the responses to
detailed product installation questions. The answers to the product
installation questions are kept in response files which contain specific
responses to each installation question.  The response files are unique to each
product.  Each product provides either a utility or a model which the system
administrator can use to generate the response files.  A procedure file which
may be tailored is set up by a system administrator and stored on the code
server.  This procedure file contains the commands which initiate product
installations for other CID enabled products such as IBM LAN Server 3.0.

CID provides the ability to individually tailor PCs or groups of PCs. Previous
solutions allowed for cloning, where software is distributed by duplicating the
files across the network.  These duplicated files did not always fit individual
workstation environments and sometimes required extensive changes from the
local user.  With CID technology, individualized support is now enabled for
OS/2 products and applications, so that users can automatically receive new
software already configured for their computers.  DOS and Windows users will
continue to be supported in the short term by cloning, with integrated support
for DOS clients to be provided by mid-1993.

Among the products that are being delivered to implement the CID process are:

 o LAN NetView Start, which allows administrators to manage and plan the
   configuration and installation of OS/2 software across the network.

 o Network Transport Services (NTS/2), which provides NetBIOS connectivity and
   helps execute instructions generated by Start about installing software on
   the workstation.

 o NetView Distribution Manager/2 (NetView DM/2), which will now provide
   expanded software distribution and installation capabilities, including
   change management and recovery, across standalone or interconnected LANs
   from a single site on the LAN.

 o Enhancements to NetView Distribution Manager (NetView DM) for an MVS host,
   which, in conjunction with Netview DM/2, will now allow centrally controlled
   distribution and installation, as needed, of system software, user and
   vendor software, software changes and data files.

 o Software Profile Management Facility, which works with NetView DM to store
   descriptions, or "profiles," of groups of users with similar
   characteristics, simplifying software installation and updates for a large
   number of workstations.

 All system and application software to be installed using this method must be
 CID enabled. OS/2 Version 2.0, OS/2 LAN Server 3.0, NTS/2 v1.0 and OS/2
 Extended Services Database Manager are all CID enabled.  Enabling consists of
 allowing installation to be redirected to a network drive, and the ability to
 provide user input through a response file.

 In addition to CID enabling our own products, IBM is encouraging vendors to
 provide CID enabled applications. IBM also announced agreements with
 independent software vendors (ISVs) who intend to enable selected products to
 take advantage of CID.  To date, a total of 164 vendors have committed their
 products to become CID-enabling, including Computer Associates, Describe,
 Lotus, Micrografx, Novell, Software Publishing Corp., Symantec and
 WordPerfect.


ΓòÉΓòÉΓòÉ 11.3.3. Commitment to open standards ΓòÉΓòÉΓòÉ

One of the most important aspects of IBM's systems management strategy,
including OS/2 systems management, is IBM's intention to esnure
interoperability with a broad range of other vendors' systems management
products. That is why the IBM systems management products aim to support
industry standards such as CMIP and SNMP, and are based on the OSI Management
Framework standards implemented by Hewlett Packard's Open View Network
Management Server Product version 3.1. Thus the IBM tools will be able to take
advantage of a programming interface consistent with the Open Software
Foundation Distributed Management Environment (OSF/DME), as well as being part
of SystemView, IBM's strategy for enterprise-wide systems management.

OS/2 is the base platform for all of these management extensions, because it is
only OS/2 that is extendable in this way, and can provide the support for these
management functions (see OS/2 for client-server ).  It is further illustration
that OS/2 is the true client of choice, as well as the server.


ΓòÉΓòÉΓòÉ 11.4. Migration from existing connectivity products ΓòÉΓòÉΓòÉ

IBM recognises that customers who wish to move towards the "super client"
platform, still have signficant investments in older connectivity products.
OS/2 2.0, as the integrating platform, provides a wide degree of support for
DOS-based connectivity products, as well as supporting other existing
networking products.


ΓòÉΓòÉΓòÉ 11.4.1. Networking on OS/2 ΓòÉΓòÉΓòÉ

Not only does OS/2 provide support for the two most popular network server
products, NetWare and OS/2 LAN Server, but it is also a platform that runs a
large range of the other major LAN software products, either as client, or
server, or both.  Many of these products had support for OS/2 1.3, but new
versions are being produced for OS/2 2.0 from vendors such as Banyan (who are
developing a requester for their VINES network system) and Digital (who are
planning support for their Pathworks product).  This makes OS/2 not only the
client of choice in these networks, but also, for many of them, the base server
platform.

DOS requester products for some of these products can be supported, running in
a VDM, though this often (as in the case of IBM DOS LAN Requester for OS/2 LAN
Server) requires booting the real version of DOS in a VDM (see Virtual Machine
Boot (VMB) ). Although DOS network drivers can often be run in a VDM, they can
only provide services to that individual VDM, since there is usually no Virtual
Device Driver for the protocol stack or the Media Access Control driver (eg
802.2). Obviously, this restriction is usual for OS/2 2.0 (see DOS device
drivers ), and in most cases causes no loss of function where a device is
dedicated to a single application (as it usually is for fax cards and
scanners). However, it tends to defeat the purpose of networks to have the
resources available to only one application, and therefore OS/2-based network
requesters and drivers are recommended whenever they are available (many
vendors already have or are working on OS/2 2.0 requester code for their server
product; contact your vendor for details).


ΓòÉΓòÉΓòÉ 11.4.2. DOS communications applications under OS/2 ΓòÉΓòÉΓòÉ

Because of OS/2's extensive compatibility with existing DOS and Windows
applications, it can even run DOS-based communications applications. This
includes not only popular asynchronous communications products such as ProComm
Plus, but also IBM's own DOS 3270 and 5250 products, Personal
Communications/3270 and DOS PC Support/400. The communications aspects are
straightforward, as OS/2 is designed to handle multiple concurrent protocols
and even background communications with more reliability than is possible under
DOS extender environments such as DOS/Windows 3.x (see Virtual Device Drivers
(VDDs) for more discussion of how it does this).

However, both Personal Communications/3270 and DOS PC Support/400 require some
customisation before they can be made to run satisfactorily under OS/2 2.0: the
first requires tailoring the DOS Settings, the second requires booting the
"real" DOS in a VDM to support special functions like shared folders (which
uses a block device driver) - see Appendices A and B in OS/2 Technical
Compendium - Volume 2: DOS and Windows Environment (GG24-3731-00) for more
details.

There are, even with these settings, some restrictions when running these
applications:

 o File transfer must be executed from the same VDM as the emulator runs in
   (you may need to enable session switching to the VDM DOS prompt via the DOS
   Setting KBD_CTRL_BYPASS)

 o Limitations in PC Support function (only Basic DOS, not Extended DOS
   support; other DOS, Windows or OS/2 applications cannot access PC
   Support/400 facilities)

 o Sharing of Token-Ring Adapter (if using Token Ring rather than DFT or
   Twinax) with other applications is not possible without an 802.2 VDD. This
   restriction disappears if the 802.2 VDD from NTS/2 is installed (see DOS
   device drivers and IBM Network Transport Services/2 ).

 Because of these restrictions, it is recommended to use OS/2 versions of these
 emulators and communications functions, which appear in Extended Services for
 OS/2, because of the higher function, easier installation and access of
 resources across DOS, Windows and OS/2 applications. Nevertheless, the support
 of most functions for the DOS applications under OS/2 enables, for many users,
 a more than adequate migration. This is in contrast to some of the press
 reports concering Windows/NT, which warn that compatibility with existing
 DOS-based connectivity programs and device drivers is likely to be extremely
 limited, forcing users to consider buying new connectivity software if it is
 available by the time Windows/NT ships. This is, of course, one of the many
 compatibility issues that have to be encountered when a new platform is
 introduced.


ΓòÉΓòÉΓòÉ 12. Futures ΓòÉΓòÉΓòÉ

It is of course important, as well as examining the strengths of OS/2 2.0, the
current release, to look at the future of OS/2 and some of the areas in which
it will develop.

OS/2 will continue to evolve to satisfy new requirements and bring forward new
technologies. With OS/2 2.0 we have designed the system not just for 1992, but
as a platform for many developments throughout the 90s.

The OS/2 32-bit architecture (OS/2 2.x) represents the base for the immediate
future. OS/2 2.0 has the functions that customers need today, and has been
designed to carry through to the next major steps, into the world of
object-oriented technology and distributed systems. This section examines some
of the areas in which OS/2 will be enhanced to meet the needs not only of
today's "super client" (see The changing PC environment and OS/2 for
client-server ), but of the long term vision of the "window on the world".  The
OS/2 direction is towards a single client system, encompassing existing
investments and harnessing new technologies like object and multimedia, and a
scalable, robust server platform exploiting the increasing power of the
hardware, and distributed networking support based on open standards.


ΓòÉΓòÉΓòÉ 12.1. OS/2 1992 developments ΓòÉΓòÉΓòÉ

By the middle of 1992, IBM had delivered:

 o OS/2 2.0 base system
 o Extended Services for OS/2
 o OS/2 LAN Server 2.0

 By the end of 1992 and into early 1993, IBM intends to consolidate on the
 early success of OS/2 2.0, by delivering updates to address the following
 issues:

 o improved device driver support

 o enhanced "Seamless Windows" capability

 o performance and memory enhancements

 o enhanced WIN-OS/2 support

 o extensions for multimedia and pen

 The current hybrid 16-/32-bit PM graphics engine will be replaced by more
 32-bit technology.  This will allow at the same time 32-bit screen device
 drivers to be delivered for VGA, SVGA and XGA.  It is intended that these
 drivers will not only improve screen performance, but also deliver high
 resolution "Seamless Windows"  capability for resolutions above VGA (see  High
 resolution support ). IBM plans to update WIN-OS/2 function to include Windows
 3.1 features.  Work is continuing to reduce the memory requirements of the
 system, and to improve performance in low-end configurations.  Such work will
 produce performance benefits in all configurations.

 Further multimedia extensions (MMPM/2) releases will ship in 1993, adding
 video and image capabilities to the audio functions shipped in the first
 release, which became available in June 1992.  OS/2 Pen extensions and a
 developers' toolkit are planned for late 1992 or early 1993.

 During the same period, IBM will produce device adaptation kits to ensure that
 more drivers for disks, displays and printers will appear from third party
 vendors.  Some of these may be available via IBM and public bulletin boards.
 If you have a query about a specific device, you are advised to contact the
 vendor in question first, to understand their development timeframes and
 proposed distribution methods.

 Many of the individual changes described above will be made available in a
 service pack before the end of 1992. Some selective fixes are already being
 made available through bulletin boards and via Compuserve. Other function,
 such as the WIN-OS/2 3.1 support, is currently in beta test.

 These are just the enhancements in the base product. Also planned are a series
 of enhancements to the systems extensions, including a new release of OS/2 LAN
 Server, enhancements to Communications Manager and the LAN Enabler, as well as
 further developments in automated configuration, installation and
 distribution. These will take place between the end of 1992 and early 1993.


ΓòÉΓòÉΓòÉ 12.2. 32-bit system extensions (communications, database, LAN) ΓòÉΓòÉΓòÉ

OS/2 2.0 is the base for Extended Services for OS/2, which provides a powerful
set of communications and database functions, and for OS/2 LAN Server version
2.0.  The first releases of Extended Services for OS/2 and LAN Server (versions
1.0 and 2.0 respectively) on the OS/2 2.0 base are 16-bit only, in order to
provide the same system on both OS/2 2.0 and 1.x.  This will allow customers to
standardise on common systems extensions across mixed 1.x and 2.0 (16- and
32-bit) bases.

However, future releases of both Extended Services for OS/2 and LAN Server will
be full 32-bit products, taking advantage of the 32-bit environment to allow
even better performance, concurrency and throughput.  In addition, Novell will
provide a 32-bit version of NetWare on the OS/2 2.0 base, fulfilling the
commitment made in the IBM-Novell February 1991 joint announcement.

Using these 32-bit extensions will allows customers to fully exploit 32-bit
performance and throughput across the entire system.


ΓòÉΓòÉΓòÉ 12.3. Multimedia ΓòÉΓòÉΓòÉ

As applications become more sophisticated, multimedia technology embedded in
mainstream applications as well as in separate applications will become
increasingly important.

OS/2 is already an excellent platform for multimedia, as products such as IBM's
Audio Visual Connection (AVC), M-Motion and the ActionMedia II Developer's
Toolkit have shown. But the 32-bit OS/2 environment allows easier development
of more sophisticated multimedia applications, and will give the potential to
include multimedia features in many other applications, thus making its use
more widespread. In particular, the multi-tasking and overlapped I/O
capabilities of OS/2 will allow the kind of applications to be developed that
are not feasible under environments like Windows, that are based on DOS.

Multimedia Presentation Manager/2 (MMPM/2) is a series of extensions to OS/2
enabling it to handle multiple media (audio, images and video) in a consistent
way. Current DOS, Windows and OS/2 multimedia applications (IBM examples
include Storyboard Live!, AVC and Linkway) all include their own multimedia
device support and use their own unique data formats. MMPM/2 provides a level
of standardisation by offering:

 o a hardware-independent layer, the Media Control Interface (MCI), which
   allows new functions, devices and data formats to be added in a modular way

 o a common data specification (RIFF) agreed by both IBM and Microsoft, and
   common between the OS/2 and Windows multimedia extensions

 MMPM/2 provides data streaming and synchronisation services to enable easy
 management of and transfer of data between devices. MMPM/2 also presents a
 series of "applets" which control and play devices like MIDI devices, digital
 audio, and Compact Disc.  The Multimedia Presentation Manager Toolkit/2
 (MMPMTK/2) is also available to help programmers write OS/2 multimedia
 applications. It includes language bindings for C and MASM, sample programs
 and documentation. The MCI has both a procedural message interface for C and
 MASM, and an interactive string interface. The latter allows easy
 incorporation of multimedia function into a variety of applications (including
 productivity applications like spreadsheets and word processors).

 The multimedia extensions for Windows will run under the WIN-OS/2 environment,
 but users and developers of multimedia may prefer to use the OS/2 facilities,
 which provide as wide a range of device support, data compatibility through
 formats like RIFF, but greater function, performance, and device utilisation.
 For example, OS/2's support for sharing of media devices between multimedia
 applications is superior to that possible under Windows.

 Overall, OS/2 provides a better multimedia environment that Windows, because
 of:

 o Better encapsulation of system resources by OS/2.  Under Windows 3.x the
   programmer needs to be aware of directly controlling the system resources.

 o Better stability of OS/2, especially in the area of multi-tasking which
   provides improved coexistence of applications with less coding effort.  For
   example, yield points required under Windows 3.x are not necessary with
   OS/2.

 o Better graphics, such as Bezier functions, on OS/2.

 o Better performance, through use of the flat memory model and pre-emptive
   multi-tasking.

 o more capacity for large data objects (image, sound) through the flat memory
   model

 The combination of better multi-tasking and the support for threads leads to
 better synchronisation of the multiple data streams needed for multimedia.  An
 example is synchronising digital audio with analog video for a firing cannon
 or a talking head.  OS/2 "fast threads" are an enhancement specifically added
 to improve the performance of threads for multimedia applications.  In Windows
 3.x, synchronisation is left entirely to the application. Developers have to
 write it themselves, thus increasing development time and cost. OS/2 controls
 multiple accesses to resources more effectively than Windows, so that audio
 and video can run without noticeable interruption while loading other
 applications. Such seamless integration of multimedia into the normal business
 desktop is more difficult to achieve in an environment like Windows, that does
 not provide pre-emptive multi-tasking.

 Multimedia applications frequently need to deal with large memory objects for
 bit maps, audio streams, or even streams of bit maps. These objects are much
 easier to manipulate in the flat 32-bit memory model provided by OS/2 2.0.

 All of these features will make OS/2 2.0 the multimedia platform of choice.

 IBM and Apple announced, in July 1991, the two companies' intention to
 collaborate on multimedia standards.  In October 1991, IBM and Apple announced
 the formation of an independent, joint venture company, Kaleida, to develop
 multimedia specifications and technologies.  This brings two of the leaders in
 the multimedia industry together, and increases the possibility of a
 broad-based industry standard.


ΓòÉΓòÉΓòÉ 12.4. Pen-based computing ΓòÉΓòÉΓòÉ

Pen-based computing is likely to be an important means of expanding the use of
computers in the next few years.  IBM has explored the use of Go Corporation's
PenPoint operating system for dedicated pen-based portable systems.  IBM
believes that some new applications may require the use of technology
specifically designed to exploit the pen interface.  Nevertheless, applications
for existing systems may also benefit from pen-based extensions, particularly
on desktop machines, where the pen may prove, in some circumstances, to be a
better input tool than those currently available.  IBM is exploring these
options through technology which we have demonstrated publicly, using pen
extensions for OS/2.  In future, as the technology develops, the tablet and
desktop systems will both offer OS/2 and Pen extensions.  It shows once again
how OS/2 is the base for most of IBM's innovative new technology in software.


ΓòÉΓòÉΓòÉ 12.5. Systems management ΓòÉΓòÉΓòÉ

Some companies in the desktop marketplace operate only in the PC arena, and
their strategies display little understanding of the difficulties of
configuring, maintaining and managing large volumes of PCs in a highly
connected environment. As companies' use of PCs grows, and their importance in
the corporate network increases, systems management of these distributed PCs
becomes of fundamental importance. The business platform of the 90s will need
to be a manageable platform, else the costs of keeping the system running will
endanger the benefits.

There is already a range of products available for OS/2 to support the systems
manager, including NetView Distribution Manager/2 and LAN Automated
Distribution/2 to help automated installation, SPM/2 for performance and
resource management, and DCAF for remote diagnosis (see Systems management ).
OS/2 will also become a full participant in IBM's SystemView strategy and more
products will be delivered to support the process of fault reporting, remote
diagnosis, asset management, software delivery and maintenance.  It is easier
to provide this support on a true multi-tasking platform, which can accommodate
administrative processes or threads capturing management data, while processing
its normal local applications.  The limitations of DOS (and therefore of
Windows) confine the function that can be provided to such systems.


ΓòÉΓòÉΓòÉ 12.6. Presentation Manager futures ΓòÉΓòÉΓòÉ

PM is the strategic SAA API for GUI development. IBM is fully committed to its
continued support and future enhancements. It has not been announced yet how
and in what timeframe the following will be delivered in product form, but they
represent some of the areas for future development:


ΓòÉΓòÉΓòÉ 12.6.1. 32-bit implementation ΓòÉΓòÉΓòÉ

It is planned that the internals of PM will be migrated to a full 32-bit
implementation.  (In OS/2 2.0, a full 32-bit API is already provided - future
changes simply affect the way PM works internally).  This will give improved
performance (it is anticipated that this change may improve performance for
many applications running on the Workplace Shell desktop). The first stage of
this is being provided in the Service Pack available by the end of 1992, with
the 32 bit PM Graphics Engine. Later work will move the PMWIN subsystem to a
full 32 bit implementation.  In addition, parts of PM are currently written in
16-bit Assembler, and are being rewritten in C for greater portability in
preparation for a move to a portable version of OS/2.


ΓòÉΓòÉΓòÉ 12.6.2. Continuing object-oriented direction ΓòÉΓòÉΓòÉ

PM already exhibits some characteristics of an object-oriented environment,
especially in programming for the Workplace Shell and the System Object model
(SOM) - see  System Object Model (SOM) . This direction will continue, not only
in the method of programming, but also in the user interface, driven by the
increasing object-orientation of SAA Common User Access (CUA). SOM itself will
evolve to offer increasing object content to OS/2.


ΓòÉΓòÉΓòÉ 12.6.3. Distributed PM ΓòÉΓòÉΓòÉ

This technology will allow an OS/2 PM application to be distributed across a
network to other OS/2 PM systems, to X Terminals or workstations running the X
Window system, or to DOS/Windows machines running an X server.  This means that
32-bit OS/2 PM applications will be made available to 286 based DOS/Windows or
OS/2 1.x PCs, and X terminals or workstations connected to the OS/2 PM
application via a network using the X11 protocol.  In essence, the OS/2 PM
application acts, in X terminology, as an X client.  X server function (where
an application running on a UNIX RISC machine can appear in a window on a PC
running OS/2) has already been delivered with TCP/IP for OS/2 v1.2. These
developments allow OS/2 to integrate more fully into the open systems world as
well as providing a wider user base for OS/2 PM applications.


ΓòÉΓòÉΓòÉ 12.7. Object-oriented environments ΓòÉΓòÉΓòÉ

In looking ahead to the future, a key challenge to the IT industry, customer
and commercial developers alike, is the ability to deliver software solutions
in a more timely and cost effective manner.  Object-oriented (OO) technologies
have proven to make software development and maintenance easier, faster, less
prone to error, and therefore less expensive.  Object-oriented programming is
now being endorsed by the software industry as a more productive programming
approach, encouraging greater re-use of code.  It is also more suitable for
object-oriented user interfaces, like OS/2 2.0's Workplace Shell.

One of IBM's goals for Personal Systems operating systems is to provide an
object-oriented development and operational environment that is customisable,
allowing developers and users to take incremental advantage of new
technologies, while protecting their investments in existing applications.

We are well on our way to achieving this with OS/2 2.0.  OS/2 itself already
exhibits many aspects of object-oriented programming, particularly in the
System Object model (SOM), the object model that underpins the Workplace Shell
(see System Object Model (SOM) ). Furthermore, the Workplace Shell itself has
many characteristics of an object-oriented user interface (see An
INFORMATION-oriented user interface )

IBM also intends to encourage object-oriented development for OS/2 2.0. OS/2
will continue to be enhanced with extensions to improve support for
object-oriented programming languages, as well as enhancing SOM.  SOM is a
technology for packaging software objects.  It allows objects to interoperate
without requiring that they be written in the same language or compiled
together.  SOM is the key element which allows applications to integrate with
the desktop facilities of the Workplace Shell.  It supports objects written in
C today.  C++ and other languages will be supported in the future.  IBM intends
to extend SOM, to provide application frameworks to further increase programmer
productivity, and to provide tools to assist end users with visual programming
(assembly of objects). IBM will enhance SOM to be compliant with the Object
Management Group's (OMG's) Common Request Broker Architecture (CORBA). OMG is
the leading object technology consortium that has published CORBA.  Adherence
to this standard will provide management for distributed heterogeneous networks
comprised of multivendor operating platforms.

Customers can start to build applications with object-oriented tools today
under OS/2, not only with C using SOM, but also with products like Enfin/2 and
Digitalk's Smalltalk/V PM . Furthermore, Borland have announced an agreement
with IBM under which Borland will supply their C++ object-oriented development
tools for OS/2 2.0, thus helping programmers who want to use C++ for
object-oriented development under OS/2 2.0.  Other object-oriented development
tools vendors are also endorsing the OS/2 environment by supplying their tools
for OS/2 2.0.

IBM has made significant investments of its own in object-oriented programming,
of which SOM and the Workplace Shell are clear examples. Through alliances, IBM
is supplementing its own technology with that of the leaders in the
object-oriented industry, in order to provide for the future development of
OS/2.

The agreement between IBM and Apple, announced in October 1991, included both
companies' intention to form a joint venture company, Taligent, to develop a
next-generation operating environment based entirely on object-oriented (OO)
technology. IBM and Apple had independently come to the conclusion that
object-oriented technology is key to solving the ever-increasing application
development challenge. The two companies had been involved in developing
object-oriented technology in-house for some time. One of the key objectives in
forming Taligent was to bring the benefits of this technology to customers
sooner than either partner could have achieved alone.

IBM will licence Taligent's system, as will Apple and other hardware system
manufacturers. IBM and Apple are both contributing technology to the Taligent
venture. Among Apple's contributions was their "Pink" technology and among
IBM's offerings was SOM.

Taligent's technology will be used separately by both Apple and IBM as the core
of new products expected in the mid- to late-90s.  These products will operate
in parallel to, and complement the evolution of, OS/2 and AIX. Over time IBM
intends to utilize a subset of Taligent's object services and frameworks to
benefit OS/2 application development and enable future compatibility with
Taligent's environment.

Taligent's system software environment will emerge in the mid-90s, targeted at
specific market segments that can readily leverage this technology. Once the
Taligent system is available, IBM intends to create an OS/2 "personality" as a
vehicle for protecting application investments. This will provide a path for
customers who want to take advantage of the Taligent system.

Therefore, in the mid to late 90s, OS/2 and the new object-oriented environment
will co-exist, and customers will be able to choose between an OS/2 system or a
full object-oriented environment.  But even then, not all customers may need or
want to adopt a full object-oriented environment, and will stay with OS/2 as
OS/2's object-oriented content increases.  OS/2 will remain the mainstream IBM
Personal Systems operating system, and will continue to be developed and
enhanced through the 90s.  Since OS/2 itself will become increasingly more
object-oriented, and its applications will run in the new environment,
evolution towards a full object-oriented environment can be made gradually and
seamlessly over time.  IBM believes there will continue to be many customer and
hardware requirements that demand OS/2, after the availability of Taligent.


OS/2 - an object-oriented future

This approach is possible because OS/2 2.0 already contains many
object-oriented features, such as the System Object Model, and the Workplace
Shell user interface.  Because of OS/2's object-oriented content, and because
OS/2 applications will continue to run in the new system, OS/2 is the platform
best suited to evolve towards a fully object-oriented environment.

Some have tried to suggest that IBM's direction towards a future
object-oriented environment in some way threatens OS/2.  The opposite is the
case:  the IBM-Apple announcement endorses and strengthens the OS/2 strategy.
Since OS/2 already displays significant object-oriented content, and since OS/2
applications will be fully supported in the new object-oriented environment, it
follows that using, programming for and deploying OS/2 is an excellent way to
secure an object-oriented direction.  If the future is object-oriented, OS/2 is
the way to get there.


ΓòÉΓòÉΓòÉ 12.8. Distributed computing ΓòÉΓòÉΓòÉ

IBM recognises the increasing importance of open networking, linking to mixed
vendor environments, both clients and servers.  In May 1990 the Open Software
Foundation (OSF) announced the Distributed Computing Environment (DCE), a group
of technologies aimed at simplifying the work for users and application
developers in these complex computing environments.  In endorsing DCE, IBM
subsequently announced not only support for DCE on AIX but also the intent to
extend the Systems Application Architecture (SAA) to incorporate key elements
of DCE.  As one of the SAA systems, OS/2 will be a platform for the delivery of
the key elements of DCE.

For those not familiar with DCE, it consists of a number of key technologies.
Of these, six are of particular interest for distributed environments including
OS/2, and can be summarised as follows:

 Remote Procedure Call (RPC)
           The basic notion is that procedures called by an application may
           actually be run on a computer somewhere else in the network. The RPC
           mechanism takes care of the communications details so that writing
           distributed applications approaches the simplicity of applications
           on a single machine.

 Distributed Naming Service
           This provides a single naming model throughout the distributed
           environment.  Resources such as servers, files, disks, or print
           queues are identified by name independent of the physical location
           in the network. Full X.500 support is provided.

 Time Service
           Many distributed applications need a single time reference to
           properly determine event sequencing and duration.  The time service
           provides a mechanism for synchronising each computer in the network
           to a recognised time standard.

 Security Service
           Provides the network with authentication, authorisation, and user
           account management.  Authentication validates the identity of a user
           or service to prevent fraudulent requests.  Authorisation is the
           process of determining whether an authenticated user should have
           access to a resource.  These facilities are made available through a
           secure communications capability provided by the RPC.

 Threads Service
           A facility to support concurrent programming, much like threads in
           OS/2.  This will be used by other DCE components to implement their
           services.

 Distributed File System
           Joins the file systems of the nodes in the network through a
           consistent interface that makes global file access as easy as local
           file access.  The Distributed File System should provide users with
           a uniform name space, file location transparency, and high
           availability.

 IBM's intention is that OS/2 LAN Server will evolve towards a full distributed
 LAN system, providing DCE services as described above. OS/2 LAN Server will
 incorporate architectures and industry standards which fully meet customer
 requirements and will include technologies such as:

 o Distributed Relational Database Architecture (DRDA)
 o Open Software Foundation (OSF) Distributed Management Environment (DME)
 o OSF's Distributed Computing Environment (DCE)
 o Transarc/ENCINA Online Transaction Processing

 OS/2 is a key part of IBM's plans for the delivery of key elements of
 distributed computing. IBM has already shown technology demonstrations of OS/2
 participating in a distributed environment along with AIX.  Distributed
 computing support will make OS/2 an even more open platform, as both a client
 and a server.


ΓòÉΓòÉΓòÉ 12.9. AIX interoperability ΓòÉΓòÉΓòÉ

IBM is committed to providing greater co-existence and interoperability between
SAA and AIX systems.  OS/2 will participate in this strategy.  This does not
involve merging function, but retaining the unique strengths of the two
systems.  The aim is to make it easier for customers to build mixed networks
combining the best of both OS/2 and AIX, RISC and Intel hardware, according to
their applications.

Part of this strategy involves putting compatible key systems components, such
as relational database, on both platforms. As well as providing a 32-bit
database on OS/2 in future, IBM will also provide a compatible 32-bit database
for AIX, and support client operations between AIX and OS/2 databases. Another
element of the strategy is to improve co-existence by providing networking
support. Products like TCP/IP for OS/2, already exist to fulfil this
requirement, and IBM intends to strengthen OS/2-AIX inter-networking in future
through DCE, DME and other technologies.


ΓòÉΓòÉΓòÉ 12.10. Future Windows compatibility ΓòÉΓòÉΓòÉ

OS/2 2.0 supports Windows 3.0 applications by including modified Windows code
under the cross-licencing agreement with Microsoft. The March 1992 release of
OS/2 2.0 does not contain support for Windows 3.1, since at the time when OS/2
2.0 shipped, Windows 3.1 was not available.  It would be impossible to plan
support for a product that had not shipped by the time OS/2 2.0 was available.
IBM plans, and is able, to support Windows 3.1 at a later point, if it proves
necessary (see OS/2 1992 developments and Windows 3.1 ). In fact, on April 7th,
1992, the day after Microsoft shipped Windows 3.1, IBM demonstrated the Windows
3.1 Program Manager running under OS/2 2.0.

It is important to understand that OS/2 2.0 supports Windows applications, not
Windows.  Windows support in OS/2 is only relevant for the Windows applications
that OS/2 customers wish to use.  IBM continues to licence the DOS/Windows
source code, and has rights to all source code in development until September
1993, in order to continue to provide support for 16-bit Windows applications.
Microsoft has not made its future plans clear on 16-bit Windows application
support, but it may be difficult for Microsoft to persuade its customers to
accept future versions of 16-bit Windows that do not support today's 16-bit
Windows applications.  IBM considers that it has the ability to provide support
for today's generation of Windows 16-bit applications, as long as is necessary.

There are, as yet, no 32-bit Windows applications available, because Microsoft
does not plan to ship its first 32-bit Windows platform until some time in
1993.  However, there are a growing number of OS/2 applications:  hundreds are
already shipping, and over 1000 have been announced for shipment by the end of
1992 or early 1993.  OS/2 will therefore have the largest number of 32-bit
applications for some time.  Therefore, the trend in the marketplace towards
real 32-bit applications, and the continuing success of OS/2, may make Windows
support a moot point.  The issue may be rather what levels of OS/2 32-bit
compatibility can Microsoft build into their future products.

Since many of the applications currently available or under development for
16-bit Windows 3.x will also be available for 32-bit OS/2, future Windows
compatibility may cease to be an issue, since running native OS/2 versions of
applications will be superior to running the Windows versions even in WIN-OS/2
(see Porting Windows applications to OS/2 ).  Support for Windows applications
is intended mainly as a migration to OS/2 2.0, but investment in Windows
applications should not be considered a long-term strategy for customers
planning an OS/2 future.  Many vendors now understand the need to provide real
OS/2 versions of their software for competitiveness' sake, and are not relying
on running their Windows version under OS/2 to address the OS/2 opportunity
properly.  Furthermore, the evidence suggests (see Windows applications ) that
Windows applications have not made anything like the same impact on the market
as Windows itself.  IBM will continue to monitor the continued need for
supporting Windows applications, and will exercise its skills and intellectual
rights to do what its customers require.


ΓòÉΓòÉΓòÉ 12.11. Portable version of OS/2 ΓòÉΓòÉΓòÉ

The joint IBM-Microsoft statement at Comdex in November 1989, indicated that
both companies were committed to producing a version of OS/2 that could run on
non-Intel processors such as RISC, and include US Department of Defense
security at the C2 level and symmetric multiprocessing. IBM remains committed
to this direction.

The most important part of the work in portability lies in ensuring that
applications are easily portable to any new platform.  The other element of
portability is to provide a portable operating system kernel (the low level
code that interfaces with the processor).  In fact, the importance of the
latter has often been exaggerated in relation to the former:  there is no point
in having a portable kernel if you cannot move your applications easily.

IBM has already made great progress in the first step with the 32-bit OS/2 API,
which eliminates many of the dependencies of the 16-bit Intel-based
architecture.  This provides the potential of a 32-bit code base which is ready
to take advantage of a future move of the kernel to other processors. The
kernel may change underneath, but the API must be established and preserved.
It is also clear in the design of OS/2 2.0 how IBM is already preparing many of
the key components of OS/2 (such as the subsystems like PM and the Workplace
Shell, and the API set) for easier portability and to accommodate future
directions.  In contrast, although Microsoft has publicised its portable
kernel, the other elements required for portability, specifically a full 32-bit
API with multi-threading, interprocess communications and advanced graphics,
are not yet delivered.  And it is unclear from their public disclosures about
Win32s (see OS/2 - a 32-bit API - TODAY )  how to make a straightforward
migration to take advantage of RISC, without changes to the code base.  The
Windows API today remains 16-bit, and 32-bit exploitation, including the full
benefits of portability, remain a future promise.

As for the choice of kernel, IBM has a variety of options, through licencing
agreements.  IBM is working on a range of technologies, and will announce its
direction when it has fully evaluated the available technology in the light of
customer requirements.  Suffice it to say that although the "NT" in Microsoft's
future system, Windows/NT, stands for "New Technology", the idea of a portable
micro-kernel is not new, and other examples already exist in a mature form,
including the OSF's micro-kernel based on the Carnegie-Mellon Mach technology.
IBM has chosen not to integrate Windows/NT code into its future offerings.  But
NT is by no means the only way of achieving the objectives stated in November
1989.

As far as customers and application developers are concerned, if portability is
a key issue, 32-bit application development under OS/2, rather than migration
from 16-bit DOS and its extensions, is the clearer path.


ΓòÉΓòÉΓòÉ 12.12. Conclusion ΓòÉΓòÉΓòÉ

OS/2 is therefore not only taking advantage of today's requirements, and the
wide range of DOS, Windows and OS/2 applications that already exist, but
provides an immediate future for powerful 32-bit developments, including a
32-bit API and the potential to integrate with the new OS/2 Workplace Shell
user interface.  The requirements of the workstation of the late 1990s for an
object-oriented platform supporting multimedia, DCE and systems management, can
only be served by a robust, architected 32-bit platform.  That platform is
OS/2.


ΓòÉΓòÉΓòÉ 13. Appendices ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 13.1. Comparison tables ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 13.1.1. DOS environments ΓòÉΓòÉΓòÉ

The following notes refer to the table on the next page.

  1. See Comparison with memory usage under DOS ,  Amount of memory and Memory

  2. See MVDM memory management and Expanded and Extended Memory Also see
     Standard mode for Windows 3.x's EMS support.

  3. The phrase "none/switch" means that no individual DOS application can
     overcommit memory, but the real mode portion can be moved to disk to make
     room for another DOS application.  However, extended or EMS memory
     allocated by the application is not switched to disk.  OS/2 1.3 can swap
     the DOS application to disk when running protected mode applications.
     Windows 3.x 386 enhanced mode can overcommit up to four times the physical
     memory on the machine.  OS/2 2.0 is limited only by the amount of
     available disk space.

  4. Although the default is to swap through the file system, Windows 3.x 386
     enhanced mode does allow swap space to be pre-allocated, and gain improved
     performance by avoiding the DOS file system. Because this disk space is
     pre-allocated, none of it is available to be shared dynamically for any
     other use.  OS/2 2.0 implements access to the swap space via the file
     system for both FAT and the HPFS.  The OS/2 2.0 implementation provides
     the flexibility of a dynamically sized swap file combined with good
     performance.

  5. OS/2 2.0 and Windows 3.1 provide windowing of DOS applications on the
     Workplace Shell desktop in all text and VGA graphics modes, while Windows
     3.0 only supports windowing of text and CGA modes.  According to
     Microsoft, Windows/NT will not support windowed VGA graphics.

  6. Although Windows 3.x does include a print spooler, and printing
     concurrently from DOS applications is not supported.  Windows permits only
     one DOS application to print and requires that other DOS applications be
     suspended if they attempt to print concurrently.  Use of a DOS print
     spooler (loaded prior to Windows 3.x.)  is not a viable solution, since
     printing concurrently from multiple DOS sessions causes all the output to
     be jumbled together on the same page.  Windows does warn of a device
     conflict in use of the printer in the latter case and offers a choice on
     how to proceed, but whatever the choice made, the same incorrect output
     results.  OS/2 2.0 provides correct spooling of printer output from
     concurrent DOS applications.

  7. Some DOS applications are extremely timing sensitive, mostly
     communications applications using high data rates.  These are supported in
     all systems when the application is in the foreground.  However, in DOS,
     OS/2 1.3., Windows 3.0 real mode, and Windows 3.x standard mode, the
     application is suspended while in the background and so cannot satisfy any
     timing constraint. In 386 enhanced mode, Windows 3.x provides the option
     of setting exclusive mode, so a timing sensitive application can be run in
     the foreground without interference due to time slicing.  However, all
     other applications are suspended while this DOS application is running in
     this mode.  In some cases the need for exclusive mode can be avoided by
     manually adjusting the relative priorities.  The ability to dynamically
     manage priorities permits OS/2 2.0 to multi-task timing critical
     applications both in the foreground and background.  Detailed
     configuration of idle time detection is also possible in the DOS Settings
     (see DOS Settings ).

  8. Although Windows 3.1 has addressed some of Windows' limitations in terms
     of stability, it is still based on DOS, and therefore still prone to
     problems caused by DOS-based TSRs which take the system out of protected
     mode into real mode (see Reliability and protection and Reliability ).

  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  Γöé Table 9. Comparison of DOS environments                                                                                                    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé                         Γöé               Γöé                Γöé           WINDOWS 3.0 ON IBM DOS 5.0           Γöé   WIN 3.1 ENH  Γöé               Γöé
  Γöé                         Γöé               Γöé                Γö╝---------------Γö¼----------------Γö¼---------------+  MODE WITH DOS Γöé               Γöé
  Γöé                         Γöé  IBM DOS 5.0  Γöé    OS/2 1.3    Γöé      REAL     Γöé    STANDARD    Γöé    ENHANCED   Γöé       5.0      Γöé    OS/2 2.0   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Conventional Memory     Γöé 622 KB        Γöé 529 KB         Γöé 558 KB        Γöé 571 KB         Γöé 569 KB        Γöé 577 KB         Γöé 633 KB        Γöé
  Γöé - with EMS & Mouse (1)  Γöé 601 KB        Γöé                Γöé               Γöé                Γöé               Γöé                Γöé               Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Memory w/ LAN Attach    Γöé 543 KB        Γöé 486 KB         Γöé 386 KB        Γöé 391 KB         Γöé 441 KB        Γöé 477 KB         Γöé 633 KB        Γöé
  Γöé - configured as PCLP    Γöé               Γöé                Γöé               Γöé                Γöé               Γöé                Γöé               Γöé
  Γöé   Receiver              Γöé               Γöé                Γöé               Γöé                Γöé               Γöé                Γöé               Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Memory w/3270 Attach    Γöé 522 KB        Γöé 495 KB         Γöé 486 KB        Γöé 492 KB         Γöé 541 KB        Γöé 549 KB         Γöé 633 KB        Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Extended Memory (XMS)   Γöé 16 MB         Γöé none           Γöé 16 MB (total) Γöé 16 MB (total)  Γöé 16 MB (total) Γöé 16 MB (total)  Γöé 16 MB(per app)Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé EMS 4.0 Memory(2)       Γöé 16 MB         Γöé none           Γöé 16 MB (total) Γöé none           Γöé 16 MB (total) Γöé 16 MB (total)  Γöé 32 MB(per app)Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Physical RAM for DOS    Γöé 0-1 MB        Γöé 0-640 KB       Γöé 0-1 MB        Γöé 0-1 MB         Γöé Any/Paged     Γöé Any/Paged      Γöé Any/Paged     Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Memory Overcommit(3)    Γöé None/Switch   Γöé None/Swap      Γöé None/Switch   Γöé None/Switch    Γöé 4 x RAM       Γöé 4 x RAM        Γöé Avail Disk    Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Swap File(4)            Γöé File System   Γöé File System    Γöé File System   Γöé File System    Γöé Physical      Γöé Physical       Γöé File System   Γöé
  Γöé                         Γöé               Γöé                Γöé               Γöé                Γöé (Preallocated)Γöé (Preallocated) Γöé (Dynamic)     Γöé
  Γöé                         Γöé               Γöé                Γöé               Γöé                Γöé or File SystemΓöé or File System Γöé               Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Number of DOS Apps      Γöé 16            Γöé 1              Γöé 16            Γöé 16             Γöé 16            Γöé 16             Γöé >32           Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Background Execution    Γöé No            Γöé No             Γöé No            Γöé No             Γöé Yes           Γöé Yes            Γöé Yes           Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Invocation              Γöé Shell/Cmd     Γöé Icon           Γöé Icon          Γöé Icon           Γöé Icon          Γöé Icon           Γöé Icon          Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Windowed(5)             Γöé No            Γöé No             Γöé No            Γöé No             Γöé Yes           Γöé Yes            Γöé Yes           Γöé
  Γöé                         Γöé               Γöé                Γöé               Γöé                Γöé (Text, CGA)   Γöé (Text, VGA)    Γöé (Text, VGA)   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Cut & Paste             Γöé No            Γöé No             Γöé Yes           Γöé Yes            Γöé Yes           Γöé Yes            Γöé Yes           Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Print Spooling(6)       Γöé Yes           Γöé Yes            Γöé No            Γöé No             Γöé No            Γöé Yes            Γöé Yes           Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Installable File System Γöé No            Γöé Yes            Γöé No            Γöé No             Γöé No            Γöé No             Γöé Yes           Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Direct Hardware Access  Γöé Yes           Γöé Yes            Γöé Yes           Γöé Yes            Γöé Yes           Γöé Yes            Γöé Yes           Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Timing Dependent Apps.(7Γöé Foreground    Γöé Foreground     Γöé Foreground    Γöé Foreground     Γöé Exclusive OptiΓöénExclusive OptioΓöé Foreground/   Γöé
  Γöé                         Γöé               Γöé                Γöé               Γöé                Γöé (Manual)      Γöé (Manual)       Γöé Background    Γöé
  Γöé                         Γöé               Γöé                Γöé               Γöé                Γöé               Γöé                Γöé (Automatic)   Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé DPMI                    Γöé No            Γöé No             Γöé No            Γöé No             Γöé Yes           Γöé Yes            Γöé Yes           Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé VCPI and DOS Extenders  Γöé Yes           Γöé No             Γöé No            Γöé No             Γöé No            Γöé No             Γöé No            Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γöé                                                                                                                                            Γöé
  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  Γöé Continues after serious Γöé Rarely        Γöé Rarely         Γöé Rarely        Γöé Rarely         Γöé Sometimes     Γöé Often          Γöé Yes           Γöé
  Γöé Application errors (8)  Γöé               Γöé                Γöé               Γöé                Γöé               Γöé                Γöé               Γöé
  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 13.1.2. OS/2 2.0 compared with Windows 3.0/3.1 ΓòÉΓòÉΓòÉ

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 10. OS/2 2.0 compared to Windows 3.0/3.1                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé WINDOWS 3.1   Γöé OS/2 2.0      Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Hardware                                                       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Processor                      Γöé 286; 386SX+   Γöé 386SX+        Γöé
Γöé                                Γöé (1)           Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Minimum hard drive             Γöé Approx 9MB    Γöé Approx 13MB   Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Hard drive for Full install    Γöé 11MB - plus   Γöé 27.6MB        Γöé
Γöé                                Γöé 50% of        Γöé               Γöé
Γöé                                Γöé remaining     Γöé               Γöé
Γöé                                Γöé partition for Γöé               Γöé
Γöé                                Γöé swap file     Γöé               Γöé
Γöé                                Γöé (default) (2) Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Largest hard drive             Γöé 1GB           Γöé 64GB (HPFS)   Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Largest file size              Γöé 1GB           Γöé 2GB           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SCSI exploitation              Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé File System options            Γöé FAT only      Γöé Enhanced FAT  Γöé
Γöé                                Γöé               Γöé or HPFS       Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Memory                                                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Physical Memory Limit          Γöé > 16 MB       Γöé > 16 MB       Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Virtual Memory Limit           Γöé 4 x Physical  Γöé 512 MB per    Γöé
Γöé                                Γöé               Γöé process (or   Γöé
Γöé                                Γöé               Γöé Disk space)   Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Memory Model                   Γöé Segmented (64 Γöé Flat memory   Γöé
Γöé                                Γöé KB)           Γöé objects       Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multi-tasking (3)                                              Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multi-tasking - DOS Applica-   Γöé Time Slicing  Γöé Pre-emptive   Γöé
Γöé tions                          Γöé               Γöé Time Slicing  Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multi-tasking - Windows & OS/2 Γöé Co-operative  Γöé Pre-emptive   Γöé
Γöé Apps                           Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Priority                       Γöé Static (set   Γöé Dynamic       Γöé
Γöé                                Γöé by user)      Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Dispatchability                Γöé Process       Γöé Thread        Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé System Services                Γöé Serial        Γöé Parallel /    Γöé
Γöé                                Γöé               Γöé Overlapped    Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Reliability/Protection (4)                                     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Protection between Applica-    Γöé Limited       Γöé Protected     Γöé
Γöé tions                          Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Kernel protection - DOS Appli- Γöé Limited       Γöé Protected     Γöé
Γöé cations                        Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Kernel protection - Windows &  Γöé Limited       Γöé Protected     Γöé
Γöé OS/2 Apps                      Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Remains in protected mode (5)  Γöé No - access   Γöé Yes           Γöé
Γöé                                Γöé to real mode  Γöé               Γöé
Γöé                                Γöé possible      Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Reliability/Availability/ServicΓöé None in 3.0.  Γöé Standalone    Γöé
Γöé (RAS) Support (6)              Γöé In 3.1: Error Γöé Dump, Error   Γöé
Γöé                                Γöé Logging/Dump  Γöé Logging,      Γöé
Γöé                                Γöé via           Γöé Trace Utili-  Γöé
Γöé                                Γöé Dr.Watson; No Γöé ties & APIs   Γöé
Γöé                                Γöé Trace APIs or Γöé               Γöé
Γöé                                Γöé Trace format- Γöé               Γöé
Γöé                                Γöé ting          Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Compatibility                                                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multiple Concurrent DOS Appli- Γöé Yes (enhanced Γöé Yes           Γöé
Γöé cations                        Γöé mode only)    Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Windows 2.x Applications       Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Windows 3.0 Applications       Γöé Most (7)      Γöé Most          Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Clipboard support              Γöé Windows and   Γöé Windows, DOS  Γöé
Γöé                                Γöé DOS only      Γöé and OS/2      Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé DDE support                    Γöé Windows apps  Γöé Windows and   Γöé
Γöé                                Γöé only          Γöé OS/2 apps     Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OLE support                    Γöé Yes           Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé 16-bit OS/2 Applications       Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé 32-bit OS/2 Applications       Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Printing and Fonts                                             Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Print spooling                 Γöé Limited (8)   Γöé Yes, for all  Γöé
Γöé                                Γöé               Γöé applications  Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Adobe Type Manager standard    Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Network printing support       Γöé Some          Γöé Full (9)      Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Background printing perform-   Γöé Unpredictable Γöé Predictable   Γöé
Γöé ance                           Γöé               Γöé (10)          Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé National Language Support                                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Number of Language Versions    Γöé 12            Γöé 16            Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Data Interchange               Γöé ISO8859/CP819 Γöé CP850 (con-   Γöé
Γöé                                Γöé (different    Γöé sistent       Γöé
Γöé                                Γöé from DOS)     Γöé throughout    Γöé
Γöé                                Γöé               Γöé OS/2)         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Host connectivity/Interchange  Γöé 3rd party     Γöé Included in   Γöé
Γöé                                Γöé               Γöé Extended Ser- Γöé
Γöé                                Γöé               Γöé vices for     Γöé
Γöé                                Γöé               Γöé OS/2          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Code Page                      Γöé Single        Γöé Selectable    Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Other Factors                                                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Full 32-bit APIs               Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Concurrent High Speed Comms    Γöé Unreliable    Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Background Comms (11)          Γöé Unreliable    Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé OEM Hardware Support           Γöé Yes           Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Development Tools              Γöé Yes           Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Command Language               Γöé .BAT          Γöé .BAT, .CMD    Γöé
Γöé                                Γöé               Γöé and REXX      Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Installation migration for     Γöé Limited       Γöé Yes           Γöé
Γöé existing apps                  Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 10. OS/2 2.0 compared to Windows 3.0/3.1                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé WINDOWS 3.1   Γöé OS/2 2.0      Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé User Interface                                                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé CUA compliance                 Γöé Graphical     Γöé Workplace     Γöé
Γöé                                Γöé Model ('89)   Γöé Model ('91)   Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Icons representing non-loaded  Γöé No (3rd       Γöé Yes           Γöé
Γöé files on desktop               Γöé party)        Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Place icons anywhere on        Γöé No (files in  Γöé Yes           Γöé
Γöé desktop                        Γöé File Manager, Γöé               Γöé
Γöé                                Γöé programs in   Γöé               Γöé
Γöé                                Γöé Program       Γöé               Γöé
Γöé                                Γöé Manager,      Γöé               Γöé
Γöé                                Γöé printers - no Γöé               Γöé
Γöé                                Γöé icons)        Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Group windows                  Γöé Single-layer  Γöé Multi-layer,  Γöé
Γöé                                Γöé (can't put    Γöé hierarchical  Γöé
Γöé                                Γöé group inside  Γöé folders       Γöé
Γöé                                Γöé another       Γöé               Γöé
Γöé                                Γöé group)        Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Customise GUI look/feel        Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé (Workplace    Γöé
Γöé                                Γöé               Γöé Shell,        Γöé
Γöé                                Γöé               Γöé Windows 3.x,  Γöé
Γöé                                Γöé               Γöé OS/2 1.x)     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Context Menus                  Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Drag/Drop across entire Shell  Γöé Windows 3.0 - Γöé Yes           Γöé
Γöé environment                    Γöé No.  Windows  Γöé               Γöé
Γöé                                Γöé 3.1 - File    Γöé               Γöé
Γöé                                Γöé Manager only  Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Object Management              Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Graphical Install              Γöé Yes           Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Intelligent fonts              Γöé Windows 3.0 - Γöé Yes (Adobe    Γöé
Γöé                                Γöé No (ATM sepa- Γöé Type Manager  Γöé
Γöé                                Γöé rate pur-     Γöé for OS/2 &    Γöé
Γöé                                Γöé chase).       Γöé Windows -     Γöé
Γöé                                Γöé Windows 3.1 - Γöé 1200 fonts)   Γöé
Γöé                                Γöé Yes (TrueType Γöé               Γöé
Γöé                                Γöé - 650 fonts)  Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Long file names                Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Applets                        Γöé Yes           Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Consistent GUI logon           Γöé No - requires Γöé Yes           Γöé
Γöé                                Γöé Network       Γöé               Γöé
Γöé                                Γöé vendor        Γöé               Γöé
Γöé                                Γöé utility       Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Interactive Tutorial           Γöé Yes           Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Command Reference              Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Advanced Connectivity(12)                                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Client and Server platform     Γöé No            Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Multiple Concurrent Protocols  Γöé Limited       Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SNA LU6.2                      Γöé 3rd party     Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé APPN                           Γöé 3rd party     Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé TCP-IP                         Γöé 3rd party     Γöé IBM TCP-IP    Γöé
Γöé                                Γöé               Γöé for OS/2      Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé Systems Management             Γöé 3rd party     Γöé Various from  Γöé
Γöé                                Γöé               Γöé IBM (13)      Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SQL Database Server            Γöé MS SQL Server Γöé Yes           Γöé
Γöé                                Γöé (requires     Γöé               Γöé
Γöé                                Γöé OS/2)         Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé SQL Database Client            Γöé 3rd party     Γöé Yes           Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé NFS                            Γöé 3rd party     Γöé IBM TCP-IP    Γöé
Γöé                                Γöé               Γöé for OS/2      Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé X-Windows server               Γöé 3rd party     Γöé IBM TCP-IP    Γöé
Γöé                                Γöé               Γöé for OS/2      Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
Γöé                                Γöé               Γöé               Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

  1. Although Windows 3.1 will run on a 286, this does not enable enhanced mode
     support, which is required to be competitive with OS/2 function
     (multi-tasking DOS applications, demand paging, 32-bit support).

  2. See Disk space

  3. See Multi-tasking of DOS applications , Multi-tasking and Performance

  4. See Reliability , Reliability and protection and Protected mode operation

  5. See Reliability , Reliability and protection

  6. Windows 3.1 uses Dr.Watson, OS/2 2.0 uses SYSLOG and Standalone Dump

  7. Windows 3.1 will not run some Windows 3.0 applications, which will need
     updates. Compatibility notes are listed in the APPS.HLP file. Several
     Windows 3.0 applications need updated versions to run on Windows 3.1. OS/2
     2.0 runs all but a very small minority of Windows 3.0 applications, as
     well as all the Windows 2.x applications that Windows 3.1 will no longer
     support (no real mode support provided) - see Real mode (NOT AVAILABLE IN
     WINDOWS 3.1) and 386 Enhanced mode

  8. Print spooling is not provided by Windows 3.1 for DOS applications, only
     for Windows applications. OS/2 2.0 provides print spooling for DOS,
     Windows and OS/2 applications

  9. OS/2 2.0 has extensive user print management capabilities (40 APIs vs 12
     APIs in Windows 3.1) for querying, holding, releasing and deleting jobs
     (including a graphical view of job and queue status).

 10. OS/2 consistently outperforms Windows with background print operations, in
     multi-tasking environments

 11. See notes on Background Execution in Appendix A on DOS applications.

 12. OS/2 2.0's "Yes" answers here are all using Extended Services for OS/2
     except where stated.  It is important to note that the Windows column
     refers to Windows specific programs (i.e. written to explicitly take
     advantage of Windows GUI, memory addressability, or time-slicing).
     Although there are many DOS connectivity options, and they may be usable
     under Windows, the integration of these complex subsystems and any
     co-residency of two or more options (eg TCP/IP and SNA) is completely the
     responsibility of the customer as a custom integration effort.  Moreover,
     Windows on DOS has substantial architectural limitations which make
     multiple network connections difficult to integrate than under OS/2 (lack
     of memory, lack of protection, and weak multi-tasking support).  OS/2's
     base environment provides tools and system support designed to allow this
     type of multi-connectivity installation.  Besides, all the extra software
     required for these functions under OS/2 comes from IBM, and one can
     therefore anticipate a greater degree of integration (see OS/2 for
     client-server ).

 13. See Systems management


ΓòÉΓòÉΓòÉ 13.2. Hardware requirements and performance ΓòÉΓòÉΓòÉ

The main reference to OS/2 system requirements is the OS/2 2.0 Information and
Planning Guide (G326-0160-00), and the equivalent guides for Extended Services
for OS/2 and OS/2 LAN Server.  Anyone planning installation of OS/2 across
several workstations should obtain these guides.  In this section we will
discuss only the key issues - for the detail, you should consult the
Information and Planning Guide. This section only discusses issues relating to
the base system, not to the extensions, though many of the principles apply to
both.


ΓòÉΓòÉΓòÉ 13.2.1. Minimum requirements ΓòÉΓòÉΓòÉ

OS/2 2.0 is designed for personal computers with the following minimum
requirements:

 o Intel (or compatible) i386SX microprocessor or above
 o 4MB of memory
 o 60MB hard disk with 15-30MB of free disk space
 o 2-button mouse or other pointing device

 Please note that this is a minimum. Many will be satisfied with this
 configuration if simple tasks are undertaken, but for more powerful
 multi-tasking and larger applications, more memory may be required. There is a
 trade-off to be made between memory and performance, in particular: OS/2 can
 work around a limit in physical memory by swapping to disk, but since disk
 access is slower than memory access, this will tend to reduce overall
 performance, which will show itself more in switching between applications
 than in the performance of an individual session.

 OS/2 2.0 will not run on machines equipped with an Intel 80286 processor.
 Therefore, computers such as the IBM PC AT, PS/2 Model 30-286, and Models 50,
 50Z, and 60 cannot be used with OS/2 2.0.  However, OS/2 2.0 does support
 non-386 based machines that have been upgraded with a 386 or 486 processor
 using the Aox Micromaster, Intel SnapIn, or Kingston SX/Now! card.

 In addition, OS/2 2.0 is supported on a broad range of IBM-compatible systems,
 including models from Compaq, AST, Olivetti, Toshiba, Hewlett Packard, Dell,
 Gateway, Wang, DEC, NCR, Tandy, ACER, CompuAdd and many others.

 The certification of compatibility is based on IBM's tests of key functions of
 OS/2 2.0, based on selected model configurations provided by the manufacturers
 of these non-IBM hardware systems.  Test results are available on CompuServe,
 IBM Forums (OEM and OS2ARENA), and other bulletin boards.  If you need
 additional information, please consult your hardware supplier. If you are
 using a specific model, and wish to have it certified, please check with your
 IBM representative or Authorised Dealer.  If it has not been tested by IBM,
 IBM welcomes your help in making contact with the manufacturer to have the
 machine tested.  IBM wishes to make the range of OS/2 compatibility as broad
 as is possible.

 In practice, OS/2 has been designed to operate correctly with a wide range of
 hardware, and the evidence from many of the users who have registered their
 copies already (see Broad hardware support ) indicates that OS/2 2.0 is
 already running on a large number of different machines.


ΓòÉΓòÉΓòÉ 13.2.2. Processor ΓòÉΓòÉΓòÉ

Because of its 32-bit addressing power, the OS/2 2.0 operating system requires
a computer that has a system unit equipped with an Intel (or compatible) i386
(or higher) microprocessor.  The i386SX microprocessor provides adequate
performance for those who work in lower-demand application environments.  In
most environments that demand multiple concurrent processes, the i386DX will be
adequate for satisfactory performance.  The IBM 386SLC chip offers high
performance from a 386SX design, and along with the new 486SLC chip, offers
outstanding price-performance for an OS/2 system. Systems equipped with the
386SLC represent a viable entry point for a multi-tasking OS/2 client.
486SLC-based systems represent an excellent option for throughput even of heavy
multi-tasking loads.  With prices of 486SX systems being reduced, they can be a
cost-effective option for client workstations.  For computers that will be used
as network servers, consider the i486 series. Also consider the 486 as a base
processor for those who expect to switch frequently and rapidly among a large
number of concurrent tasks.


ΓòÉΓòÉΓòÉ 13.2.3. Memory size ΓòÉΓòÉΓòÉ

Memory and disk storage are closely related because of the ability of the
operating system to manage the allocation of memory resources between real
physical memory and hard disk space. In general, it is important, when
calculating memory and disk requirements, to work on the concept of "working
set", in simple terms the sum of physical memory and swap file size. The
balance of physical memory installed versus swap space is key to determining
overall performance - the more working set is gained from swap space rather
than physical memory, the lower overall system performance.

4MB is adequate for an entry-level workstation running few tasks.  This enables
users to run applications or other system utility programs concurrently, but it
presents a constrained environment (limited memory) for some large
applications.  In limited memory configurations, performance of applications
might be reduced, particularly when the operating system is loading an
application or switching from one application to another or to the desktop.
This is as a result of paging, as the code required is loaded to memory from
disk, and the least recently used memory is paged to disk to make room.

Although more tasks can be accommodated by swapping, performance degradation
would suggest more memory would be required for more intensive multi-tasking.
However, an OS/2-only workstation (ie no DOS or Windows applications) with a
LAN requester can perform acceptably in a 4-5MB configuration.  This indicates
that the entry level configurations are suitable for some client scenarios.

To estimate probable working set requirements, estimate 2.5MB for the base
system without any applications, 0.6MB per concurrent DOS session, and 1MB per
concurrent WIN-OS/2 session. (The latter two figures assume the default amounts
of XMS, EMS and DPMI memory installed, which are 2048K, 2048K and 2MB
respectively - the actual figure may therefore be more, or less, depending on
the settings chosen.) Thus a system running DOS and Windows applications can
run satisfactorily in 6MB. A connected workstation (eg LAN requester plus 3270
emulators) will require around 8MB (though note the low entry point above for
OS/2-only clients with just a LAN requester).

The amount of memory installed can be an important factor in performance,
particularly when swapping between applications. Since working sets of 1-2MB or
more are being switched, the performance difference between a 4MB and a 6MB
configuration can be substantial; a further increase to 8MB is appreciable, but
not usually to the same extent. The system tends to handle overcommitment on
memory well above the 8MB point. Large applications and heavy multi-tasking
will benefit from 8MB or more.

Though adding more memory inevitably adds to the cost of the system, it is to
be remembered that the cost of memory is decreasing. Although OS/2 2.0 will
tend to require more memory than Windows 3.1 for equivalent software
configurations, the cost of the memory will often be less than $100 at today's
memory prices. Many customers are finding that the extra costs for memory are
compensated by the increased function and stability that OS/2 offers. Customers
hoping to achieve the combination of a 32 bit, stable multitasking platform, on
an affordable hardware configuration, may consider this trade-off between
function and system requirements. Furthermore, independent analysts have
predicted that Windows/NT will require an even higher configuration than OS/2
2.0. Gartner Group has told its customers that it believes "a mainstream
platform for Windows/NT will be a 486DX with 12 to 16 megabytes of RAM (and up)
on the workstation"

It is to be remembered that in all the above estimates for OS/2 memory
requirements, results will vary with the configuration of the machine and the
applications run.  Also, performance is a subjective matter - few people agree
on what is acceptable relative to the cost of a configuration.  Customers are
recommended to carry out their own benchmarks to assess the most suitable
configuration for their requirements.


ΓòÉΓòÉΓòÉ 13.2.4. Disk space ΓòÉΓòÉΓòÉ

The requirements stated in this section are for the operating system, swap
space, and print spool jobs. They do not consider space required for extra
applications and data.

Although the maximum space required for OS/2 installation is 27.6MB plus swap
space, the minimum installation can be as little as 12.7MB (no DOS or Windows
support), 14.6MB (DOS, but no Windows support) and 16.9MB (DOS and Windows
support). These are taken from the cumulative total in the selective install
option; the total in each of these scenarios can be lower still by eliminating
selected files after installation. Typical scenarios will require less than
20MB and sometimes only 15MB.

The decision of whether to install certain components can make a large
difference to the space taken: WIN-OS/2 requires 3MB, Productivity applications
1.3MB, tools and utilities 3.6MB and games 0.8MB. The optional systems
utilities (eg BACKUP, ATTRIB, TREE, RECOVER, SORT), which are often removed
after installation on both OS/2 and DOS machines, take up 1.2MB.

The amount required for swap space will vary according to system load.  The
system allocates a minimal swap file on loading; this defaults to a figure
based on the physical installed memory (the Information and Planning Guide has
a table with the detailed figures), for example, a 6MB swap file for a system
with 4MB of memory, a 4MB swap file for an 8MB machine.  The figure can be
modified by the user at installation time, or later by modifying the SWAPPATH
parameter in CONFIG.SYS.  The installation program also allows the user to set
the location of the SWAPPATH to a different partition.  This can be a good idea
if the main partition is 30MB or less.

If you are choosing the type of machines to use as OS/2 machines, remember that
for any environment that uses virtual memory (swapping to disk to create more
memory), a fast disk is recommended.  This is an important factor, especially
for those who expect to switch frequently and rapidly among a large number of
concurrent tasks.

Some figures in the industry have criticised the amount of space taken by OS/2
2.0, but there is always a cost associated with high function. In fact, if you
consider what OS/2 offers:

 o a full DOS environment
 o a complete Windows environment
 o a copy of the OS/2 kernel and system, with compatibility for both 16- and
   32-bit applications
 o a font manager for both OS/2 and Windows (ATM), plus associated fonts
 o a series of utilities, including a file search tool, a charting package, and
   a personal organiser
 o an object-oriented graphical shell
 and then compare the likely disk space required to assemble all this function
 under either DOS or Windows (here are some suggested equivalents):

 o DOS version 5.0
 o Windows 3.0 or 3.1
 o ATM for Windows
 o (For example) XTree Gold, Micrografx Charisma, and Polaris Packrat
 o Norton Desktop for Windows
 then it is likely you have taken at least as much space (and probably more)
 than OS/2 2.0. (And that's ignoring the extra monetary cost of acquiring these
 separate third party applications.)

 Furthermore, the differences between Windows 3.1 and OS/2 2.0 in disk space
 are exaggerated.  Although Windows will nearly always take less for the base
 installation, you can see from the above figures that OS/2 2.0 can come within
 3 or 4MB of the Windows total.  Moreover, the figures quoted by many people do
 not mention the fact that if you choose, during Windows installation, to have
 a permanent swap file (chosen by many Windows users to gain acceptable
 performance), the default is to take 50% of the free space on your partition.
 This can result in an overall disk usage (system plus swapper) of close to
 OS/2's and sometimes more (dependent on the size of the partition). OS/2
 allows detailed and granular control over what is installed, so it is at least
 easy to know what your likely requirements are.

 Furthermore, many newer applications take large amounts of disk space anyway.
 A full installation of Word for Windows version 2.0 takes up to 15Mb of disk
 space. This puts the requirements for the operating system into some
 perspective.

 For those concerned about disk space in general, data compression tools such
 as Stacker, which are available on DOS, are under development for OS/2.  Stac
 Electronics have announced their intention to produce an OS/2 version of
 Stacker, which will be available before the end of 1992.  Other vendors are
 producing OS/2 disk compression tools, which are expected to ship in 1992.


ΓòÉΓòÉΓòÉ 13.2.5. Performance considerations ΓòÉΓòÉΓòÉ

IBM's performance aims for OS/2 2.0 are as follows:

 o Close to DOS for single tasking DOS applications
 o Close to Windows 3.x for single tasking Windows applications
 o Superior to Windows for multi-tasking
 o Equivalent to or better than OS/2 1.3

 It is very important to understand that achieving these aims is subject to the
 obvious limits on comparing single tasking performance:

 o DOS applications which are processor-intensive, or require continual
   servicing of interrupts, are always going to perform better in DOS where
   they do not have to share the CPU with other processes. However, despite
   this, there is little performance loss for most DOS applications in a single
   tasking scenario in a full screen DOS session. In a windowed session, screen
   scrolling and update will be affected by runnning the application within a
   window, and the extra virtualisation that needs to occur. This will
   particularly affect applications running in graphics mode. If higher
   performance is required, switch to full screen (the Alt-Home toggle allows
   flexibility: use full screen most of the time for maximum performance, but
   switch to windowed when interaction with the rest of the system (eg
   clipboard) is needed. On the other hand, DOS applications that are disk and
   I/O-intensive (such as database programs) can perform as much as 200-300%
   faster, due to the superior caching in the OS/2 FAT system, or using HPFS
   (see Enhanced FAT ). As most applications are a mix of disk and processor
   operations, comparisons will differ according to the application chosen.

 o Although for Windows applications, single tasking scenarios may be between 5
   and 20% slower, this is hardly the best basis on which to compare
   performance (since Windows is supposed to be a multi-tasking environment as
   well).  The differences mainly relate to application load time (usually
   caused by the fact that the Windows application often loads into a separate
   VDM, and then loads its own instance of WIN-OS/2.  (A real comparison would
   be to add the time to load Windows under DOS to the load time of the Windows
   application, and compare it to the total under OS/2 2.0).  Running the
   application in a Full Screen WIN-OS/2 session rather than Seamless sometimes
   yields better performance.

 o In fact, DOS applications often run faster under OS/2 2.0 than under Windows
   3.1, particularly disk-intensive applications, due to the superior FAT
   implementation (see above).

 o When considering multiple application scenarios, OS/2 shows its superiority.
   Even running two applications together can show a big difference between
   OS/2 2.0 and Windows 3.1. Try, for example, formatting a diskette from the
   DOS prompt while running another application under Windows 3.1, and compare
   the operation in OS/2 2.0. In Windows, if the format operation is in
   foreground, it can starve the background process of processor time, and if
   put to background, may scarcely progress at all. Under OS/2 2.0 the share of
   processor load is much more even. This is hardly a heavy processing load.
   Another illustrative scenario comes from the testing of National Software
   Testing Laboratories (NSTL), an independent testing and evaluation
   organisation:  to load MS Word for Windows on a PS/2 Model 57 with nothing
   else running takes 7.2 seconds with Windows 3.1 and 9.3 seconds with OS/2
   2.0. If you do the same load with an XCOPY in the background, Windows load
   time jumps to 41.1 seconds, compared with 15.3 seconds for OS/2.  When more
   than one task is being done, OS/2's performance advantage becomes evident.
   Because of OS/2's superior multi-tasking, it can run background tasks, such
   as file copying, communications, or spreadsheet recalculation, with no
   visible impact on foreground work.  With Windows, the cursor movement can
   lag behind the mouse movement, and displaying of characters can lag behind
   keyboarding to the point where system becomes almost unusable until the
   background job is done.

 Benchmarks from some sources are misleading, and are easily skewed by the
 choice of scenario. The best guide is to run your own, to simulate your own
 usage.


ΓòÉΓòÉΓòÉ 13.2.6. Tuning hints ΓòÉΓòÉΓòÉ

When considering overall performance, there are many variables, including how
balanced a processing load you want to achieve, or whether you want to give one
process as much CPU as possible. Therefore hints can only be generic, and must
be considered in the light of specific application requirements. Nevertheless,
here are a few basic ideas. More are contained in the chapter on "Optimising
Performance" in the OS/2 2.0 Installation and Planning Guide.

 o To conserve OS/2 system resources and reduce memory requirements:

    - close applications when they are not going to be used again.

    - close folders if they are not needed.

    - move commonly used functions out of folders and to the desktop, and close
      the folder that contained the object.

    - However, be careful not to overload the desktop - keep only as many
      objects as you really need

 o If certain applications are always used, put them in the Startup folder.
   This will increase boot time but have everything ready to run

 o Pre-initialising the SWAPPER.DAT file at boot time will help if a certain
   group of applications are always loaded. The setting can be made in the
   SWAPPATH parameter in CONFIG.SYS. You should be careful to observe swap
   growth beforehand, and not set the initial swapper too large, lest you have
   a detrimental effect.

 o The cache sizes for FAT and HPFS can improve performance if increased.
   Experimentation is the best way to discover the right results for your
   configuration

 o Set the system path statements (PATH and LIBPATH especially) based on usage
   patterns, so that applications are quicker to load.

 o Turn off public clipboard and DDE if sharing between Windows and OS/2
   applications is not required

 o Load Windows programs into a single WIN-OS/2 session, except those that
   require greater protection. Ensure that the DPMI_MEMORY_LIMIT is set
   appropriately

 o If XMS, EMS and DPMI memory are not required (as is the case for many DOS
   applications), set them to zero in DOS Settings

 o DOS Settings parameters can have substantial effect on relative performance
   of individual applications, and on their effect on others when running in
   the background.  See DOS Settings and Version 2.0 Volume 2:  DOS and Windows
   Environment (GG24-3731-00).  Remember that many applications require little
   attention when in background, as they are usually waiting for input, and can
   therefore safely be given little CPU.


ΓòÉΓòÉΓòÉ 13.3. Further reference materials ΓòÉΓòÉΓòÉ

Here are some useful publications on OS/2 2.0 that are either already available
or about to be published:


ΓòÉΓòÉΓòÉ 13.3.1. IBM ITSC OS/2 2.0 Technical Compendium ("Red Books") ΓòÉΓòÉΓòÉ

This is a detailed and comprehensive description of OS/2 2.0 in five volumes,
published by the IBM International Technical Support Center in Boca Raton,
Florida (the same location as the development laboratory for OS/2 2.0).  It is
essential reading for anyone needing to understand OS/2 2.0 in depth.  This
guide has borrowed much material from the Red Books.  They can be ordered
together, as OS/2 Technical Compendium  (GBOF-2254), or separately, as follows:

 Volume 1: Control Program (GG24-3730-00)
 Volume 2: DOS and Windows Environment (GG24-3731-00)
 Volume 3: Presentation Manager (GG24-3732-00).
 Volume 4: Application Development (GG24-3774-00)
 Volume 5: Print Subsystem (GG24-3775-00)

 Another important Red Book is OS/2 Remote Installation and Maintenance
 (GG24-3780-00). This contains practical instructions on how to install OS/2
 across a LAN, discussing the various approaches. It will be supplemented, by
 the end of 1992, by two other books:

 Automated CID Installation of OS/2 V2.0 (GG24-3783)
 Automated CID Install of ES 1.0, NTS, LS (GG24-3781)

 Other red books may be of interest. Here is a selection of some of the ones
 covering OS/2 and its extensions:


   GG24-3875-00 LAN SERVER 2.0 NEW FUNCTIONS AND FEATURES
   GG24-3890-00 NETWARE FROM IBM: NETWORK PROTOCOLS & STANDARDS
   GG24-3794-00 EXTENDED SERVICES FOR OS/2 DATABASE MGR NEW FEATURES
   GG24-3781-00 AUTOMATED INSTALL FOR CID ENABLED EXT SERVICES...
   GG24-3580-01 DEVELOPING A CUA WORKPLACE APPLICATION
   ZZ81-0295-00 EVALUATION OF OS/2 APPLICATION DEVELOPMENT TOOLS
   GG24-3641-01 PRACTICAL INTRO TO OBJECT-ORIENTED PROGRAMMING
   GG24-3822-00 MIGRATING FROM A DOS/WINDOWS ENVIRONMENT TO OS/2
   GG24-3749-00 MULTIMEDIA APPLICATION ENABLERS & PS/2 ULTIMEDIA
   GG24-3653-01 IBM PERSONAL SYSTEM/2 MULTIMEDIA FUNDAMENTALS

 Copies can be ordered through IBM via the publication numbers in parentheses.


ΓòÉΓòÉΓòÉ 13.3.2. The OS/2 Developer (previously Personal Systems Developer) ΓòÉΓòÉΓòÉ

This is a quarterly publication from IBM's US Developer Assistance Program
(DAP). Subscriptions can be made direct with the publishers in the US. Contact
your local IBM office for details. Its publication number is G362-0001.

The OS/2 Developer contains many articles on a wide variety of OS/2 topics, and
there have been many articles on OS/2 2.0, and on the system extensions like
Database Manager and LAN Server, as well as material on OS/2 applications and
development tools.


ΓòÉΓòÉΓòÉ 13.3.3. Personal Systems Technical Solutions ΓòÉΓòÉΓòÉ

This publication comes from the Personal Systems Competency Center in Dallas,
USA. It covers both hardware and software, and contains many useful articles on
OS/2 2.0. It is published quarterly. The publication number is different for
each issue, but all are of the type G325-50xx-00, where xx is a two digit
number. Issues 5012, 5014, 5015, 5016 and 5017 all contain useful articles on
OS/2 2.0


ΓòÉΓòÉΓòÉ 13.3.4. OS/2 White Papers ΓòÉΓòÉΓòÉ

These papers were first issued by IBM in April 1991, and a second set appeared
in January 1992.  They are an excellent guide to IBM's OS/2 strategy and future
product directions.  They include:

 o OS/2 2.0 Considerations: an excellent guide to OS/2 2.0's features, market
   positioning, application migration, and future directions (reprinted in the
   Personal Systems Developer Summer 1991 issue). This guide makes use of some
   of the material in this paper.

 o OS/2 LAN Server: a summary of current LAN offerings and future directions.

 o OS/2 System Performance Management: an overview of current OS/2 and LAN
   Server parameters and tuning facilities as well as future directions.

 o OS/2 System Management: a good overview of current IBM SAA SystemView
   facilities in OS/2 environments and future directions.

 o OS/2 Database Manager Highlights and Directions: an overview of current
   database offerings and future directions.

 o OS/2 Communications Manager Highlights and Direction: a detailed overview of
   Communications Manager function.

 o OS/2 Performance Considerations: a guide to some of the issues involved in
   tuning performance for OS/2 2.0

 o OS/2 2.0 Windows environment: an explanation of how the WIN-OS/2 environment
   is architected, and what benefits the environment has versus Windows 3.x

 o OS/2 LAN Server Positioning: a guide to the relative strengths and
   weaknesses of LAN Server versus Microsoft LAN Manager 2.0 and Novell NetWare
   3.11

 o OS/2 LAN Server Migration: how to move both clients and servers to OS/2 LAN
   Server 2.0 from various previous IBM LAN products.

 o OS/2: The Bigger Picture: an overview of IBM's OS/2 strategy and future
   directions

 o Upgrading to OS/2 2.0: a review of the various options in upgrading from
   DOS, Windows or OS/2 1.3 to OS/2 2.0, and what is required for each
   migration path

 o Getting Started with the OS/2 Workplace Shell: a brief introduction to the
   capabilities of the Workplace Shell. This is worth a read before starting on
   the shell for the first time

 o Client-Server Computing: an overview of the various IBM products that
   address the client server environment, including Extended Services for OS/2
   and OS/2 LAN Server

 o OS/2 2.0: the Development Platform of Choice: reasons why OS/2 2.0 is an
   excellent target for developers, including a review of the range of various
   development tools available

 The White Papers can be obtained from your IBM representative. They are on the
 IBM MKTTOOLS disk as WPAPERS and WPAPERS2 packages. They can be copied and
 distributed to anyone who wants to understand about OS/2.


ΓòÉΓòÉΓòÉ 13.3.5. IBM OS/2 Information ΓòÉΓòÉΓòÉ

IBM has published a variety of brochures and information about OS/2. Here is a
selection, with the publication numbers.  These can be obtained from your
dealer or IBM representative. Please note the following list is specific to
those issued in Europe. Local publication numbers may vary, and some brochures
may not be available in all countries. Contact your local IBM representative
for a list relating to your country.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Table 11. OS/2 product information                             Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé          Γöé IBM OS/2 V2.0 Product Informa- Γöé G 511    Γöé         Γöé
Γöé          Γöé tion                           Γöé 1545-01  Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé          Γöé Extended Services for OS/2     Γöé G 511    Γöé         Γöé
Γöé          Γöé Spec sheet                     Γöé 1546     Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé          Γöé OS/2 Local Area Network Server Γöé G 511    Γöé         Γöé
Γöé          Γöé 2.0 Spec sheet                 Γöé 1554     Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé          Γöé OS/2 2.0 Decision Maker's Bro- Γöé G 511    Γöé         Γöé
Γöé          Γöé chure                          Γöé 1548     Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé          Γöé The OS/2 partnership           Γöé G 511    Γöé         Γöé
Γöé          Γöé                                Γöé 1738     Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé          Γöé OS/2 - The Customer's Choice   Γöé G 511    Γöé         Γöé
Γöé          Γöé                                Γöé 1739     Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé          Γöé The New OS/2: Wouldn't it be   Γöé G U20    Γöé         Γöé
Γöé          Γöé great if...                    Γöé 2020     Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ


ΓòÉΓòÉΓòÉ 13.3.6. IBM OS/2 Applications Solutions Directory ΓòÉΓòÉΓòÉ

This is a guide, published in the US, listing most of the applications
available for OS/2 today.  There are thousands to choose from!  The main guide
is orderable through IBM as G362-0002-02, and there is a supplement of 32-bit
applications (G362-0029) which are either in development or already shipping.


ΓòÉΓòÉΓòÉ 13.3.7. CUA Vision materials ΓòÉΓòÉΓòÉ

This is a video and a companion booklet outlining IBM's vision for the way user
interfaces will develop. The booklet includes a demonstration diskette with a
graphical demonstration of the principles discussed. Both the video and the
diskette offer a fascinating insight into the principles behind the OS/2
Workplace Shell, which embodies the first stages of the vision, and into where
the Workplace Shell may be headed in future.

The video is orderable as GV26-1004-00 (VHS PAL) or GV26-1003-00 (VHS NTSC) and
the booklet as G242-0215-00.


ΓòÉΓòÉΓòÉ 13.3.8. OS/2 in the Corporate Environment ΓòÉΓòÉΓòÉ

This is a short book published by Intelligent Environments Ltd, one of the
leading vendors of OS/2 developement tools.  It is an independent view of where
OS/2 fits in the corporate computing world, including specific examples of
where customers are implementing client-server solutions using OS/2 today.
Contact Intelligent Environments for details. They are based at:

   Intelligent Environments Europe Ltd.,     Intelligent Environments Inc.
   Crystal house                             2 Highwood Drive
   PO Box 51                                 Tewkesbury
   Sunbury-on-Thames                         MA 01876
   Middlesex                                 USA
   TW16 7UL
   United Kingdom

Tel: [phone]                       Tel: [phone]
Fax: [phone]                       Fax: [phone]


ΓòÉΓòÉΓòÉ 13.3.9. OS/2 Notebook ΓòÉΓòÉΓòÉ

This is a book from Microsoft Press, edited by Dick Conklin, who is the editor
of the Personal Systems Developer, containing the best of articles from that
publication.  It includes a wide range of articles on OS/2 2.0 and its
extensions like Extended Services and OS/2 LAN Server. Its ISBN number is
1-55615-316-3.


ΓòÉΓòÉΓòÉ 13.3.10. The Design of OS/2 ΓòÉΓòÉΓòÉ

This book is co-written by Mike Kogan, one of the OS/2 2.0 System Architects,
and H.M. Deitel. It is published by Addison-Wesley (ISBN 0-201-54889-5). The
following paragraph is from the publisher's abstract:

     " The primary goal of The Design Of OS/2 is to provide insights into the
     design decisions and philosophy of the OS/2 operating system.  It
     discusses the motivation, architecture, and realization of OS/2 in the
     personal computing marketplace.  The design of the major components of
     OS/2 are described in terms of their API architecture, internal data
     structures, and algorithms.  Each area focuses on bridging operating
     systems theory to the realization of the design and implementation of
     OS/2.  Where it is significant, an objective comparison of the technical
     aspects of OS/2 and other operating environments is provided.  A key
     thrust is to describe the evolution of personal computer operating systems
     from DOS through 16-bit OS/2 and 32-bit OS/2. "


ΓòÉΓòÉΓòÉ 13.3.11. Other OS/2 Books ΓòÉΓòÉΓòÉ

There are a variety of books published on OS/2, including many new titles for
OS/2 2.0. Here are a few of the titles:

 o Using OS/2 by Barry Nance and Greg Chicares, from Que books (ISBN
   0-88022-863-6)
 o Now that I have OS/2 2.0 on my Desk - What do I do next? by Stephen Levenson
   and Eli Hertz, published by Van Nostrand Reinhold (ISBN 0-442-01227-6)
 o Inside OS/2 2.0, by Mark Minasi, John W. Little, Marlene Semple and Bill
   Camarda, from New Riders Publishing (ISBN 1-56205-045-1)
 o OS/2 2.0 Quick Reference, by Barry Nance, from Que books (ISBN
   1-56529-068-2)
 o Stepping Up To OS/2 2.0, by Robert Albrecht and Michael Plura, from Abacus
   (ISBN 1-55755-160-X)
 o OS/2 2.0 Complete, by Peter Franken, from Abacus (ISBN 1-55755-157-X)
 o Integrating Applications with OS/2 2.0, by William Zach, from Van Nostrand
   Reinhold (ISBN 0-44201-234-9)
 o Client-Server Programming with OS/2 2.0 by Bob Orfali and Dan Harkey, from
   Van Nostrand Reinhold (ISBN 0 442-01219-5)
 o Writing OS/2 Device Drivers in C, by Steve Mastrianni, from Van Nostrand
   Reinhold (ISBN 0 442-01141-5)
 o OS/2 Presentation Manager GPI, by Graham Winn, from Van Nostrand Reinhold
   (ISBN 0-442-00468-0)
 o Learning to Program OS/2 2.0 PM by Example, by Stephen A. Knight, from Van
   Nostrand Reinhold (ISBN 0-442-01292-6)
 o OS/2 Application Development Tools by Brian Proffit, from Premier Publishing
   (ISBN 1-881899-00-4)
 o Converting Applications to OS/2, by David Moskowitz et al, from Brady Press
   (ISBN 0-13-171943-2)
 o OS/2 2.0: The Usable, Portable Guide, by John Haber and Herbert R. Haber,
   from Usable Portable Publications Inc., (ISBN 0-945965-27-4)

 At the time of writing, four other books were about to made available. ISBN
 numbers were not obtainable, but IBM order numbers are supplied here:


  G362-0014   THE OS/2 2.0 USER'S GUIDE FOR THE WORKPLACE SHELL by Maria Tyne
              from Computer Information Associates,

  G362-0010   THE COBOL PRESENTATION MANAGER PROGRAMMING GUIDE by David M.Dill
              Published by Van Nostrand Reinhold

  G362-0012   COMPREHENSIVE PERFORMANCE FOR THE OS/2 2.0 DATABASE MANAGER by
              Bruce Tate, Tim Malkemus, and Terry Gray (IBM, Austin, TX).
              Published by Van Nostrand Reinhold

  G362-0013   C PROGRAMMING IN THE OS/2 2.0 ENVIRONMENT by V. Mitra Gopaul.
              Published by Van Nostrand Reinhold

 The book by Barry Nance sold its first print run in a few weeks, and moved
 into the top ten computer titles.  Even Steve Mastrianni's book, which
 addresses a more specific audience, is already into its first reprint.  In
 October, it was announced that the Barnes and Noble computer book bestseller
 list contained three of the above OS/2 books, for 17 consecutive weeks.  The
 books were the ones by Orfali and Harkey, Minasi et al., and Levenson and
 Hertz.  Sales of books are often regarded as one of the signs of a flourishing
 platform (witness the sales in books about Lotus 1-2-3, WordPerfect, and
 Windows).  This indicator also shows the amount of interest there is now in
 OS/2.

 In fact, OS/2 books are not only appearing in English. An indicator of the
 success of OS/2 is that books in national languages are appearing, a testimony
 not only to the strength of OS/2 in the countries involved, but also of its
 widespread appeal (books in English would usually be considered to reach a
 wider market, especially among computer experts, but OS/2's appeal to end
 users means a viable market at which to target books in the native language.)
 Here is a list of some OS/2 books written and published in Germany:


  "OS/2 2.0, Grundlagen und Praxis"
           von Hans Fremuth (mit Vorwort von H. Kahl) im tewi Verlag
           (in deutscher Sprache)
           ISBN 3-89362-212-8

  "OS/2 2.0, Das Kompendium"
           von Olaf Koch, Norbert Meder und Peter Scheuber (mit Beitrugen
           von Whittle und Pignatelli) im Verlag Markt & Technik
           (in deutscher Sprache)
           ISBN 3-87791-302-2

  "OS/2 - 2.0, Der Data Becker Fuhrer"
           im Verlag DATA BECKER
           (in deutscher Sprache)
           ISBN 3-89011-637-X

  "OS/2 Version 2 deutsch, Das Data Becker Handbuch"
           von Peter Franken im Verlag DATA BECKER
           (in deutscher Sprache)
           ISBN 3-89011-505-5

  "Von DOS und Windows nach OS/2 2.0, Tips & Tricks"
           von Robert M.  Albrecht und Michael Plura im Verlag DATA BECKER
           (in deutscher Sprache)
           ISBN 3-89011-543-8


  "Schnell Anleitung OS/2 Version 2 deutsch"
           im Verlag DATA BECKER
           (in deutscher Sprache)
           ISBN 3-89011-658-2

  "QuickStart OS/2 2.0, Der Einsteig in 20 Schritten"
           von Harald Babiel im SYBEX Verlag
           (in deutscher Sprache)
           ISBN 3-88745-859-1


ΓòÉΓòÉΓòÉ 13.3.12. OS/2 Monthly ΓòÉΓòÉΓòÉ

This is an independent magazine dedicated to news, views and technical
information about OS/2. It is published by:

 JDS Publishing
 PO Box 4351
 Highland Park
 NJ 08904
 USA

 Tel: [phone]


ΓòÉΓòÉΓòÉ 13.3.13. Moving to the Workplace Shell video ΓòÉΓòÉΓòÉ

This video (part number 41G5097) guides the new user of OS/2 2.0 through the
Workplace Shell.  It is meant to be a light and enjoyable introduction to the
capabilities of the shell, to encourage you to explore for yourself.


ΓòÉΓòÉΓòÉ 13.3.14. OS/2 Frequently Asked Questions (FAQ) ΓòÉΓòÉΓòÉ

This document, maintained by Timothy F. Sipples ([e-mail]), is
an excellent basic reference to many common questions and answers about OS/2.
It is available in electronic form on most of the bulletin board systems
mentioned in  OS/2 Bulletin Board Systems It is just one example of many of the
excellent reference materials and tools made available by OS/2 enthusiasts
around the world, on bulletin board systems.


ΓòÉΓòÉΓòÉ 13.3.15. OS/2 2.0 Information and Planning Guide ΓòÉΓòÉΓòÉ

This publication (G326-0160-00) gives an overview of OS/2 2.0 function, as well
as assistance in estimating memory and disk space requirements.  It is
recommended for anyone planning to install OS/2 2.0 on a number of machines.
Guides are also available for Extended Services for OS/2 (G326-0161-00) and
OS/2 LAN Server (G326-0162-00).


ΓòÉΓòÉΓòÉ 13.4. OS/2 Bulletin Board Systems ΓòÉΓòÉΓòÉ

Bulletin board systems (BBS) are often a good way of getting information about
OS/2, whether technical support, news or useful utilities.  In many countries,
IBM runs a BBS as a means of customer support; but there are also many other
BBSs run by OS/2 enthusiasts. Here is a list of some of the BBSs:


ΓòÉΓòÉΓòÉ 13.4.1. IBM Bulletin Boards ΓòÉΓòÉΓòÉ

Not all countries operate a BBS. Here is a list of some of the countries that
do, with the connection details:

 IBM Sweden

    Phone: 46+8-7932200 Dealers       46+8-7934222 Customers
    Lines: 10 Lines
    Speed: 1200-14400 Connection rate (V.32 and MNP)
           10 USR DS 14400 modems

 ********************************************************

 IBM Austria

 IBM Bulletin Board System Austria:

    Phone: [phone]
    Speed: 9600
    Lines: 2

 ********************************************************

 IBM Germany

 IBM Bulletin Board System Germany

    Fidonet : 2:241/7411.0@FIDONET
    Phone   : [phone]

 ********************************************************

 IBM Canada

 Canadian Sofware Support Center, specializing in OS/2 and OS/2 support.

  Vancouver - 604-664-6464             Montreal  - 514-938-3122
  Toronto   - 416-946-4244 or 4255

 ********************************************************

 IBM Switzerland

 Name:  IBM-BBS HITLINE Communications
 Phone: [phone] (16 lines/14000 Baud)
 ISDN:  0041 56 320 589 (1 line/128kBits/s)

 *********************************************************

 IBM Denmark

   Name: IBM OS/2 BBS
   Phone: + 45 42 88 72 22
   Lines: 3 lines
   Speed: 9600 (V32 and MNP)
   Location: Lyngby, Denmark

 ********************************************************

 IBM Belgium

 International BBS name :    The IBM Belgium BBS
 In country BBS name    :    End-User Node.
 Location: IBM Belgium s.a.  J.F.Kennedylaan 2, B-1831 Diegem.
 Modem number :              32-2-725.60.10
                             8 lines, up to 9600 bps, 8,n,1, V32  24/24
                             No MNP4 no MNP4.

 ********************************************************

 IBM USA

 IBM National Support Center BBS, located in Atlanta GA.

 1-404-835-6600 =>  First available modem
 1-404-835-6296 =>  First available Hayes Ultra
 1-404-835-5300 =>  First available USR V.32bis with ASL
 1-404-835-5578 =>  First available IBM 7855 model 10

 ********************************************************

 IBM Finland

 IBM OS/2 Bulletin Board System

       Phone: [phone]
       Speed: 9600, 8, n, 1

 ********************************************************

 IBM Spain

 Bulletin Board System IBM OS/2

  Phone: [phone]      34 1 397 58 73
         34 1 397 55 81      34 1 397 59 63
  Speed: 9600, 8, n, 1

 ********************************************************

 IBM UK

 Phone: [phone] (>12000 - V.32 MNP-5)
 Lines: 15

 ********************************************************


 IBM Israel

 Phone: [phone]
 Additional Info: 2:241/7411.0@FIDONET

 ********************************************************


 IBM Netherlands

 Phone: [phone]
 Additional Info: Lines 8 Courier Dual Standard 14K4

 ********************************************************


 IBM Norway

 Phone: [phone]

 ********************************************************


 ISM South Africa

 Phone: [phone]
 Info - Lines: 47 55 81
        Speed: 9600,8,n,1 (V32 and MNP)

 ********************************************************


ΓòÉΓòÉΓòÉ 13.4.2. Other BBSs ΓòÉΓòÉΓòÉ

The following information was provided by the US OS/2 Support Line:


O S / 2   B B S ' s   A C R O S S   T H E   W O R L D
-----------------------------------------------------

This list is a compilation of OS/2 BBS's across the world.  If you wish to
make an addition or correction to this list, please send the information to
the following (as netmail or logged onto the BBS itself):

BBS      : LiveNet, 1:170/110@fidonet, [phone]
Location : Tulsa, OK, USA
Sysop    : Dave Fisher

This list is distributed to many FidoNet nodes found in this OS/2 BBS listing
via the Fernwood distribution system.  All BBS's listed are in alphabetical
order by country, and then by BBS name.  Unless otherwise noted, all node
addresses are FidoNet.

A current list can always be file-requested from LiveNet as 'OS2WORLD'.

                                 Enjoy!


Last Update: May 14, 1992

Legend:  * : OS/2 is primary interest of board
         F : Board is a FidoNet node
         % : Entry is new or changed as of last list
        -A : HST, MNP modem
        -B : HST, MNP V.32 (and/or V.42) modem
        -C : HST, MNP V.32bis/V.42bis modem
        -D : MNP V.32/V.42bis modem
        -E : MNP V.32 modem

USA BBS's show states, International BBS's show three letter country codes.

-----------------------------------------------------------------------------

Graham Stair          3M Australia            [phone]   Aus 9600-E * F
Ian Watson            OZ-Share OS/2 BBS       [phone]   Aus 9600-E * F
Alan Salmon           PC User's Group         [phone]   Aus 2400
Felix Tsang           Programmer's BBS        [phone]   Aus 9600-E * F
Bill Bolton           Software Tools Mail Exc [phone]   Aus 9600-E * F
                                              [phone]   Aus 9600-E * F
John Della-Torre      The Poet's Dilemma      [phone]   Aus 2400-E
Norbert Fuerst        The Styrian OS/2 Jumbo  [phone]   Aus 9600-A * F
Danny Bruggeman       Hellfire                [phone]    Bel 9600-D * F
Bas Heijermans        Moving Sound OS/2 BBS   [phone]    Bel 9600-D * F
Benoit HUON           Os/2 MANiA BELGIUM      [phone]    Bel 9600-D * F
Tony Bearman          Bear Garden             [phone]   Can 9600-C * F
Chris Ange-Schultz    Home Front BBS          [phone]   Can 2400   * F
Peter Fitzsimmons     RT Labs                 [phone]   Can 9600-B * F
Gerry Rozema          The Idle Task           [phone]   Can 14.4-B * F
Jerry Stevens         The Locutory            [phone]   Can 9600-D * F
Alec Herrmann         The Nibble's Roost      [phone]   Can 14.4-B * F
Kevin Lowey           University of Saskatche [phone]   Can 14.4-C * F
Jorgen Ollgaard       Josti-BBS               [phone]    Den 9600-C * F
                                              [phone]    Den 9600-C * F
Rene Carlsen          OS/2 Task & FrontDoor H [phone]     Den 9600-A * F
Emmanuel Sandorfi     Os/2 MANiA (Help Maximu [phone]   Fra 9600-C * F
Romeo Bernreuther     CCWN-BOX                [phone]   Ger 14.4-B * F
Peter Plischka        IBM Mailbox             [phone]   Ger 9600-C * F
                                              [phone]   Ger 9600-B * F
Juergen Berger        JERRY'S OS/2-BBS        [phone]   Ger 2400-A * F %
Oliver Lass           LRZ-System              [phone]   Ger 2400   *
                                              [phone]   Ger 9600-D *
Oliver Schwabedissen  MoonFlower              [phone]   Ger 9600-C * F
Richard Clement       OS/2 Express            [phone]   Ger 9600-D * F
Harald Kipp           OS/2 Point              [phone]  Ger 9600-B * F
Michael Breukel       PC Softbox OS/2         [phone]   Ger 2400   * F
Markus Noller         Second Source           [phone]   Ger 2400   * F
Kalle Braun           Terrania City           [phone]   Ger 14.4-B   F
Thomas Tegel          The CAT                 [phone]   Ger 14.4-D * F %
Karlheinz Kissel      The_File_Store          [phone]   Ger 9600-C * F
Chris Leuder          Zaphod BBS              [phone]   Ger 14.4-B   F
                                              [phone]   Ger 2400     F
Joop Mellaart         INFOBOARD               [phone]    Hol 2400   * F
Marcel Stikkelman     PC-Square               [phone]    Hol 14.4-C * F
Pasquale Cantiello    FastForward BBS         [phone]   Ita 14.4-C * F
Luigi Ravina          Italy Network           [phone]   Ita 9600-A * F
Roberto Sonzogni      Runnin' with The Devil  [phone]   Ita 9600-C * F
Dave Jones            The TJD Support BBS     [phone]   Net 9600-A *
Terje Slydahl         PerlePorten             [phone]     Nor 9600-C * F
                                              [phone]     Nor 2400   * F
Alex Wyss             Gepard's Oracle Zuerich [phone]    Swi 14.4-C * F
Michael Buenter       MICS OS/2 Paradise      [phone]    Swi 9600-C * F
Ernesto Hagmann       PC-Info                 [phone]   Swi 9600-C * F
Mike Gove             MonuSci CBCS            [phone]   UK  9600-C * F
Phil Tuck             The TJD Support BBS     [phone]   UK  9600-C *
                                              [phone]   UK  9600-A *
Patrick O'Riva        AsmLang and OS/2        [phone]   CA  14.4-B * F
Steve Lesner          Bullet BBS              [phone]   CT  9600-B * F %
                                              [phone]   CT  9600-B * F %
Jim Dailey            Cajon Zone OS/2         [phone]   CA  9600-D * F
Bob Germer            Capital City BBS        [phone]   NJ  14.4-C * F
Dennis Conley         Communitel OS/2 BBS     [phone]   NV  14.4-C * F
Emmitt Dove           Fernwood                [phone]   CT  9600-C * F
                                              [phone]   CT  14.4-B * F
Bill Cook             GREATER CHICAGO Online! [phone]   IL  9600   * F
Bogie Bugsalewicz     I CAN! BBS              [phone]   IL  9600-C   F
                                              [phone]   IL  2400     F
n/a                   IBM National Support Ce [phone]   GA  2400
                                              [phone]   GA  9600-C
Ed June               Information Overload    [phone]   GA  9600-A * F
James Chance          Lee's Lounge            [phone]   MD  14.4-B * F
Robert McA            Live-Wire               [phone]   TX  9600-B   F
Dave Fisher           LiveNet                 [phone]   OK  16.8-C * F
Chuck Gilmore         Magnum BBS              [phone]   CA  9600-C *
Joe Salemi            Max's Doghouse          [phone]   VA  2400-A * F
Paul Breedlove        Multi-Net               [phone]   OR  9600-C *
Ron Bemis             Nibbles & Bytes         [phone]   TX  9600-A   F
Craig Swanson         OS/2 Connection         [phone]   CA  14.4-D * F
Pete Norloff          OS/2 Shareware          [phone]   VA  9600-C * F
                                              [phone]   VA  9600-C * F
Brady Flowers         Oberon Software         [phone]   MN  14.4-C *
Unknown               Omega-Point BBS         [phone]   CA  2400
Paul Beverly          PMSC OnLine Resource    [phone]   SC  2400   * F
Louis F. Ursini       Quantum Leap            [phone]   PA  2400
Ken Rucker            RucK's Place/2          [phone]   TX  14.4-C * F
Randy Edwards         Socialism OnLine!       [phone]   CO  9600-B * F
Ed Barboni            System-2 RBBS           [phone]   PA  9600-D   F
                                              [phone]   PA  9600-D   F
Mark Lehrer           The Akron Anomoly       [phone]   OH  9600-C   F
Bill Schnell          The Asylum BBS          [phone]   OK  9600-B * F
Felix Tang            The Excelsior           [phone]   CT  14.4-C * F
                                              [phone]   CT  2400   * F
Bob Hatton            The Monster BBS         [phone]   NJ  9600-A *
Woody Sturges         The OS/2 Woodmeister    [phone]   MO  14.4-C * F
Troy Kraser           The Other World         [phone]   FL  9600-D   F
Mark Wheeler          The SandDollar          [phone]   FL  9600-A * F
Art Fellner           The Soldier's Bored     [phone]   TX  9600-C * F
Bill Andrus           The Systems Exchange    [phone]   VA  9600-A * F
Unknown               WSI BBS                 [phone]   TN  2400

------------------------------------------------------------------------------


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

In this document, the i386 and i486 processors will often be referred to as 386
and 486 respectively. Where discussion relates to 386 or 486 SX or DX models
specifically, terms such as 386SX will be used. Otherwise the terms will be
used to refer to any member of the 386 or 486 family as appropriate. The term
80X86 is sometimes used to denote the range of 32 bit processors currently
shipped by Intel (ie 386 and 486 together, but NOT the 80286).


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Windows can either be hidden (the installed default), minimised to the desktop,
as happens in Windows 3.x and OS/2 1.3, or minimised to a Minimised Window
Viewer, according to the user's preference.  This can be set on a per-object
basis.


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

See, for example, the benchmarks run by NSTL in their Software Digest Ratings
Report Volume 9, Number 4


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

The Microsoft document "Microsoft Windows/NT Operating System - An Overview"
confirms that "...OS/2 supports some MS-DOS programs requiring some
special-purpose, custom device drivers, whereas Windows NT does not. Examples
are 3270 emulators, fax boards, scanners and MIDI boards." (p13)


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Quoted in Wall Street Journal, 6th August, 1992


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Windows Magazine, October 1992, p16


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

See Microsoft's document entitled "Microsoft Windows NT Operating System"


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

SPA figures quoted in Windows Magazine, November 1992


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Quoted in Windows Magazine, February 1992


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Quoted in Computing (UK), April 23, 1992


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Quoted in PC Week, March 30, 1992 - p131


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Quoted in PC Week, March 30, 1992 - p132


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Reported in Computergram Online Issue #1952 - 29th June 1992


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Quoted in PC Week, March 30, 1992 - p132


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Reported in Computergram Online Issue #1949 - 24th June 1992


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Article in Infoworld, September 14th, 1992 - p51


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Though how this "operating system" is able to load without DOS, has not been
made clear by Microsoft.


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Quoted in PC Week, July 29, 1991 - p111


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

The report in PC Magazine, May 12, 1992 - p32, said : "When CEO Bill Gates was
asked what it would take for Microsoft to write for OS/2, he said 2 million
copies in the first year - but they'll sell less than 10% of that"


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

MDI means that multiple child windows are contained within the bounds of the
parent window, and no child window can be sized beyond the bounds of the
parent. The Windows 3.1 File Manager and the behaviour of the directory windows
within it, provide an example of MDI.


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Modeless (as opposed to modal) refers to the behaviour of child windows in a
GUI.  Modal windows have to be closed or the dialog within them completed
before the parent window can be accessed.  They tend to enforce a particular
pattern of progressing through several windows (an example is in the use of
error dialogs, which tend to be modal.) Modeless means that the user may move
from the child window back to the parent without closing intermediate windows
or dialogs. An example is the "Find" dialog in the OS/2 System Editor.


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

CID stands for Configuration, Installation, Distribution - see Configuration,
Installation, Distribution (CID)


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

See PC Week July 27, 1992 - page 1. The lack of support for DOS device drivers
is confirmed in the Microsoft document "Microsoft Windows NT Operating System".


ΓòÉΓòÉΓòÉ <hidden>  ΓòÉΓòÉΓòÉ

Gartner Group - Personal Computer Research Notes, P-230-853, July 31, 1992